Had an interesting idea and wanted to see if anyone was doing anything like this

[sbeaver]

So while talking with some of the powers to be about the provisioning process one of the question that was asked over and over was "how long did that part take?"  So in an attempt to be able to answer those question  I was thinking of creating a DB that would supply metrics or timestamps of the different stages.

I was going to use this as a starting point http://www.vcoportal.de/2012/07/little-cmdb-part1/ and add another table for timestamps of the different steps and or stages.

So while I was working this out, I had a light bulb moment and thought, hey I could create another table to hold the all the properties for the virtual machine.  My thoughts would be to use the properties in that table to automatically resubmit the request using the "Request a catalog item" workflow if a original request fails.

Anybody else played around with some kind of automatic recovery from a failed provision request?

Cheers!!

Steve

[vmmeup]

Why would you need to store all the properties in an external database?  If you disable doDeletes you can make it so a failed request remains intact with it's properties and invoke a workflow to attempt to build the machine again.

-Sid Smith

http://www.dailyhypervisor.com

[sbeaver]

Sid,

Thanks for the response and hats off to you guys on some of the stuff you have shared.  To follow your suggestion I would need to have the VM break out of following the workflow stubs in that the Unprovision and Disposal workflow stubs currently follow the corporate decom process or removing agents from the OS and third party systems as well as release the name and IP back to the IP management system so with my idea I was considering finding some marker that the process had failed and once the decom had finished to resubmit the request.

Thinking about it I could use some marker to bypass the decom process of the workflow stubs to leave the VM intact.  Do you know of a way to have a state failure restart that state so if the provision stub fails for what ever reason so restart that stub?

Steve

[SeanKohler]

Well... we are pushing all of our machine data into a Postgress Table on-build (and later going to have a daily validate policy for all VCAC managed machines), but not for the purposes of Request restart.  Just want a faster reporting mechanism with direct data queries.

It wouldn't be hard to take all the request parameters into a table, and then rerun it... maybe through Omer's example of a parameterized REST call to the Blueprint?  (Using vCAC 6 REST APIs - Part 1 - Elastic Skies)

I would be interested in what you figure out if you care to share it.