Hi guys,
Is there a way of deleting finished workflows without using the Orchestrator client?
Preferably a workflow which would delete all finished workflows globally would be the optimal fit..
Within the weboperator view you can only view/delete your own finished workflows so this is not a possible solution.
Thanks in advance,
Dave
A workflow that deletes all workflow runs could be written but it is much better to configure a rule based automatic removal of the workflow runs. This could be done from the vCO configurator. For more details please take a look at the docs: http://pubs.vmware.com/vsphere-50/topic/com.vmware.vsphere.vco_install_config.doc_42/GUID8C6618C0-EC...
Insted of 0 in the configuration, you can change it to something that fits your use cases. If you set it to 5, then the server will clean all workflow tokens more than 5.
A workflow that deletes all workflow runs could be written but it is much better to configure a rule based automatic removal of the workflow runs. This could be done from the vCO configurator. For more details please take a look at the docs: http://pubs.vmware.com/vsphere-50/topic/com.vmware.vsphere.vco_install_config.doc_42/GUID8C6618C0-EC...
Insted of 0 in the configuration, you can change it to something that fits your use cases. If you set it to 5, then the server will clean all workflow tokens more than 5.
There is no delete method on the workflowToken object.
The number of kept workflow token is stored in app-server-server-vmo/conf/vmo.properties
The server runs a purge frequently and will use these settings to clean up.
Christophe.
Thanks for the reply guys.
If I understand correctly, then changing ch.dunes.task.max-workflow-tokens to 1 means that we are limited to one running workflow at a time. Is this right?
Conversely, if I lower the Max number of events, is this going to have a reaction on the running of the workflows, or just the recording of events?
Many thanks,
Dave
No, it means vCO will keep a single workflow execution record per workflow, instead of storing the 100 configured as default.
The number of concurrent workflows is set by the parameter com.vmware.vco.workflow-engine.executors-count and has a default of 300. After that the workflows are queued up to 10.000.
The event parameter is solely for events.
Christophe.
I'm going to hop on the band wagon of wanting the ability to delete finished runs programatically. We have cases where hundreds of items fail and we re-run the tasks. I don't want all of those previous failed runs to remain in the logs. Yes they eventually scroll off. Yes I know I can control how many we keep around. Yes I know I can nuke all of them from orbit. Depending on the particular workflow I like to keep the history around and don't want to brute force remove everything. What I would like to do is remove the previously failed runs once I am satisfied the work has completed successfully. I was pretty surprised to find out there was no .delete() method. Can't this be added? I know it can. I'm just being nice and asking. Don't throw me into the tirade of VMware knowing what's best for me and not allowing for this. I can click on one and delete it and I expect the same functionality via api's and in this case scriptable objects. This is really just an inconvenience and forcing me down a path I'd prefer not to follow.
I thought this can be done with the vRO multi-node plugin but this is not exposed there either. So I ended up deleting directly from the postgres database (0b3335b9-20b1-4e0f-92d2-11a4e8b5e5f9 is my workflow id):
delete from vmo_workflowtokencontent tc using vmo_workflowtoken t where t.wfexecutionstack = '0b3335b9-20b1-4e0f-92d2-11a4e8b5e5f9' and t.globalstate = 'failed' and t.id =tc.workflowtokenid returning tc.workflowtokenid;
delete from vmo_workflowtoken where wfexecutionstack = '0b3335b9-20b1-4e0f-92d2-11a4e8b5e5f9' and globalstate = 'failed' returning id;
- only for dev environments -