dont run unprovision when buildmachine fails

[kallischlauch]

Hey,

i configured EBS subscription to PRE buildmachine. here I create DNS A-record and CNO for the VM.

I also configured EBS subscription to PRE destroymachine. when VM is disposed, the workflow will remove DNS and CNO from AD/DNS

works perfect, but if I deploy a VM and accidentally provide existing productive VM Name, then my workflow checks first for existing DNS, finds one. workflow fails (good) - but then proceeds with Dispose workflow and that workflow then wipes DNS and CNO of my production machine ?!?!

What am I doing wrong?

I found similar discussion, where the solution is to track what you create and only remove what was created. But that doesnt really help, because if a user destroys a VM (normal operation) then I want to destroy the DNS/CNO. and I dont have a creation record for the existing VMs

i also found that it seems possible to trick around with those:
Configuring the Error Behavior for States and Events

State Where Error Occurs	Error State
PRE MachineProvisioned	UnprovisionMachine
PRE BuildingMachine	Disposing
PRE RegisterMachine	Finalized

To customize the timeout or error behavior, you can add custom properties to the machine for any events or states where you want to trigger an event or force a state change. Use the following examples to configure the custom properties.

• Extensibility.Lifecycle.Error.Event.{Workflow}.{State}. The value of the property is the name of the event to be triggered on in the workflow in case of timeout or error.
• Extensibility.Lifecycle.Error.State.{Workflow}.{State}. The value of the property is the name of the state in which the workflow will forcibly transition to in case of timeout or error.

But I'm not really sure how to use this, or even if that is any help.

Anyone any ideass?

[stevedrummond · Accepted solution]

You have a couple options.

If you are attempting to create DNS/AD in PRE-BuildingMachine and it fails because the records already exist for another machine, the provisioning will finish all remaining subscriptions in PRE-BuildingMachine and then move to PRE-Disposing. As a result you should have your cleanup activity for AD/DNS occur in the lifecycle state PRE-UnprovisionMachine (if you need blocking) or POST-UnprovisionMachine (no blocking) if it can only occur after the VM is destroyed; these subscriptions will never run in the above use case. This could be an issue if you do legitimately create new records in DNS/AD but another blocking subscription within PRE-BuildingMachine fails; it will never move to PRE-UnprovisionMachine as the VM was never created and thus will not clean up your created records.

If you can't or don't want the cleanup to occur within PRE-MachineProvisioned then you will need to extend your VM with a custom property. During the EBS that is supposed to create the DNS/AD records, add a custom property to your IaaS VM (vCAC:Entity) with the result (e.g., needToCleanRecords=true). Then ether filter your PRE-Disposing subscription by that property (if it has no need to run at all) or check it within the vRO workflow itself.

Of course this entire problem is solved when you're generating new names for every VM you provision. Forcing state changes will not help you in this case and I generally recommend never doing it.

[kallischlauch]

Hey Steve,
I had to read it a couple of times. going by everything you said I think my solution is the advise you mention above:
you're saying my AD/DNS cleanup operations should only ever be in pre-unprovisionmachine, so they only run when there is actually a VM removed. I think that would solve my problems. If it fails in pre-build, then that workflow will not run

[kallischlauch]

on another note. we had issues when importing. when import failed (during machine provisioned we had some tagging workflows), it also ran workflows it shouldn (in dispose).
this solution (use pre-unprovision instead of dispose) could also be a solution for this problem as well