VMware Cloud Community
Andre24680
Contributor
Contributor

custom "expire" action - need additional inputs

We have custom workflows running as part of the "expire" action, so far so good.

But we need additional parameters passed in as part of the action, which are required within the custom workflows triggered by event subscription.

for most day2 actions we just replaced the default one (like take snapshot) with a custom one, doesn't look like I can do that with "expire" and "destroy"

Any help appriciated

A.

16 Replies
qc4vmware
Virtuoso
Virtuoso

Wouldn't you just exclude those second day actions from your entitlement and create custom 2nd day activities?  How were you handling it with the other 2nd day activities you "replaced" ?

Reply
0 Kudos
Andre24680
Contributor
Contributor

Yes, that is what we are doing.

Like we have a custom “snapshot” day2 action.

The question is how do you create a custom “expire” action? I can’t see anything in vRO to expire a VM or a deployment.

Cheees

A

Reply
0 Kudos
qc4vmware
Virtuoso
Virtuoso

You need to query the deployment and/or individual deployment item for a list of its actions and execute it.  You'd likely need to change the context of the workflow to run as a service account that did have access to the "Expire" activity.  There is a vRO workflow item you can use to change the credential.

Screen Shot 2019-08-10 at 4.21.31 PM.png

Reply
0 Kudos
Andre24680
Contributor
Contributor

that sounds like a lot of customisation.

would it be possible to add/modify a custom property of the deployment?

if that would work I can just have a workflow that adds the change control ticket number into the payload and triggers the expire action or sets the lease to 0 days.

i could then read the property in the pre/post workflows?

cheers

A

Reply
0 Kudos
qc4vmware
Virtuoso
Virtuoso

I think maybe the way you are presenting the question is a bit confusing.  If you just want to modify the expiration date then sure just go ahead and set it with whatever method makes sense.  It sounded like you wanted to replace the day 2 activity for expiration which is an out of the box feature.  It sounds like you want to control the lease times?

Reply
0 Kudos
Andre24680
Contributor
Contributor

I don't want to control the lease time. I have pre and post workflows for expire and destroy - they work but the requirement is to log the activity into the ticketing system. I do have workflows for that but need from somewhere the "ticket number".

Reply
0 Kudos
Hejahida82
VMware Employee
VMware Employee

The way I have done it in the past for such situations:

1. Add a custom property to the deployment/VMs in the deployment to store the ticket number in

2. Run an event broker subscription workflow at Building Machine PRE or Requested PRE to create the ticket in 3rd party system (can even do it via an approval policy based subscription). Last step in that workflow is to update the custom property value created in step 1 with the ticket value by passing the value back to vRA using the virtualMachineAddOrUpdateProperties output parameter.

3. Run an event broker subscription workflow at PRE Expired to update/create ticket for machine disposal. Retrieve the ticket number from the payload in vRO to get the ticket number to pass to the 3rd party system.

4. Run an event broker subscription workflow at POST Expired to close off the ticket to show successful disposal of the VM.

Can do the same thing during disposal as well. For builds that failed and jumped from Building Machine PRE straight to Disposing I had a second set of workflows which were triggered in the event there was no ticket number in the custom property, that meant it was a failed build and it updated the ticket with an error status.

I can't share the code I used as its in a customer environment but happy to provide assistance if needed when you are creating the workflows.

Andre24680
Contributor
Contributor

Hi,

during the build its not a problem - we do that already.

lets say ticket number "1234" for "build a windows vm blah"

custom property -> "build ticket", value:1234

I pick that that up in the post deploy workflows and log everything into the correct ticket.

2 month later ticket number "3456" is raised to destroy this VM using the "expire' feature in vRA.

even if I have a custom property for "expire ticket" defined, I can't see a way to put a value in it after the VM has been build.

Hope that makes kind of sense?

Cheers

A

Reply
0 Kudos
Hejahida82
VMware Employee
VMware Employee

Makes sense. So lets say PRE Expire lifecycle event you run a workflow to which creates the ticket 3456 for the VM being decommissioned. Then you need that ticket number in POST Expire workflow to update it as completed and the problem is how do you get the new ticket number of 3456 during POST Expire as its not put into the payload when the VM is originally built.

I think you can still use the virtualMachineAddOrUpdateProperties output parameter to push the new ticket number into the payload as a custom property during the PRE Expire workflow. Then in the POST Expire workflow you can retrieve the value from the payload, it will show up under the properties.virtualMachineAddOrUpdateProperties.customPropertyName section of the payload rather than properties.customPropertyName section.

If that doesn't work then I think you can bypass the payload all together and stamp it onto the vCAC VM (IaaS VM object) object as a property and then retrieve it from there in the second workflow. That requires more code though as you have to find the vCAC VM object first and then run a second piece of code to update its properties. In the second workflow you have to retrieve it again and then retrieve the property value. I say I think you can do this as I'm assuming the vCAC VM object will still exist when the POST Expire workflow runs.

I can provide code to retrieve the vCAC VM based on the name and id (which you can grab from the payload) and update a property value if you need those. The code to retrieve the vCAC VM properties is out of the box action (com.vmware.library.vcac) getPropertiesFromVirtualMachine with the vRA plugin for vRO.

Andre24680
Contributor
Contributor

Quote:

Makes sense. So lets say PRE Expire lifecycle event you run a workflow to which creates the ticket 3456 for the VM being decommissioned. Then you need that ticket number in POST Expire workflow to update it as completed and the problem is how do you get the new ticket number of 3456 during POST Expire as its not put into the payload when the VM is originally built.

End Quote:

The ticket numbers are generated outside of vRA and needs to an "input" for the expire. Can I use virtualMachineAddOrUpdateProperties in any vRO workflow at any time or just in an EBS workflow?

Reply
0 Kudos
Hejahida82
VMware Employee
VMware Employee

Just as part of EBS workflows otherwise there is no payload to update as vRO has no payload concept, it's a concept within vRA.

You can use the IaaS VM object properties in any vRO workflow though to add/update properties on the VM, they would then be reflected in the properties sent by vRA to vRO as part of the payload in any EBS workflows that ran after that initial update of the VM was completed.

What's the steps for the complete process does it look something like this:

1. log ticket in 3rd party system and get ticket number

2. Expire VM in vRA and enter ticket number from step 1 as an input value

3. Expire action runs in vRA

4. Update ticket in 3rd party system via POST Expire EBS workflow using the ticket number

Reply
0 Kudos
Andre24680
Contributor
Contributor

in that case the question becomes simple, is there a way to update a custom property on a VM through a vRO workflow (outside of EBS)?

Reply
0 Kudos
Andre24680
Contributor
Contributor

2. Expire VM in vRA and enter ticket number from step 1 as an input value

that is what I can't figure out - how to have an "input" for the expire action

Reply
0 Kudos
Andre24680
Contributor
Contributor

lets say my blueprint has 2 custom properties:

buildTicket

expireTicket

how would you use "You can use the IaaS VM object properties in any vRO workflow" to update the expireTicket value?

Cheers

A

Reply
0 Kudos
Hejahida82
VMware Employee
VMware Employee

A few possibilities that I can think of.

Replace the out of the box expire action with a custom action which accepts an input. Then you can run the action to update the property on the VM or push the value into the payload before vRA performs the Expire.

Run an EBS subscription at Expire PRE and use the user action in vRO in theory it would prompt the user and you could have them enter the ticket number and then use the value to update the property on the VM

Run a PRE and POST approval policy on the Expire Action. Have a custom property set on the PRE Approval which the user populates with the ticket number. That value then gets added to the payload and can be used in the POST approval policy workflow to update the ticket status. The PRE Approval would be a standard approval policy, the POST Approval would be tied to an EBS subscription.

Your use case is a bit different to mine as you aren't creating the ticket via a vRO workflow in an EBS subscription.

Attached the action I use to update properties.

Andre24680
Contributor
Contributor

I was already thinking about the "user interaction" but just don't like how its being presented (or not presented) to the user in vRA. But I like the approval process idea. I'll give that a go tomorrow.

Thanks heaps

A

Reply
0 Kudos