How to restart a timeouted/failed/canceled/terminated cadence workflow - cadence-workflow

Hi I have a workflow with 2 activities.
Scenario. one activities is completed while executing second, URL link to which I need to communicate is down. Now when that URL is up workflows is timed out. So How can I restart Timed out workflow?
This question is inspired by a Github issue.

Cadence allows you easily restart any workflow that is already closed in any status: timeouted/failed/canceled/terminated. And even closed with success status: completed or continuedAsNew.
You can use CLI command to reset a workflow to LastDecisionCompleted or FirstDecisionCompleted resetType. LastDecisionCompleted will reset to the last point if you want to save the progress of workflows has made before timeouted. FirstDecisionCompleted will reset to beginning of workflow, like really restarting by saving only the start parameters of workflow:
./cadence workflow reset -w <wid> --reset_type LastDecisionCompleted --reason "some_reason"
If you have many workflows to reset, and your Cadence cluster has advanced visibility feature enabling your search/filter workflows by query, then you can also use batch-reset command like this:
./cadence workflow reset-batch --query <query> --reset_type LastDecisionCompleted --reason "some_reason"
You can also use reset API in client sdk to reset a workflow to a particular point.
Reset is one of the most powerful feature in Cadence for operation. Not only resetting to FirstDecisionCompleted and LastDecisionCompleted, you can easily manipulate workflow to go back to any point of time like using time machine. There are more resetTypes supported if you use "--help" to read the command manual.

Related

Can I trap the Informatica Amazon S3Bucket name doesn’t match standards

In Informatica we have mapping source qualifiers connecting to Amazon Web Services—AWS.
We often and erratically get a failure that our s3 bucket names do not comply with naming standards. We restart the workflows again and they continue on every time successfully.
Is there a way to trap for this specifically and then maybe call a command object to restart the workflow command via PMCMD?
How are you starting the workflows in regular runs?
If you are using a shell script, you can add a logic to restart if you see a particular error. I have created a script a while ago to restart workflows for a particular error.
In a nut shell it works like this
start workflow (with pmcmd)
#in case of an error
check repository db and get the error
if the error is specific to s3 bucket name
restart the workflow
Well... It's possible for example to have workflow one (W1):
your_session --> cmd_touch_file_if_session_failed
and another workflow (W2), running continuously:
event_wait_for_W1_file --> pmcmd_restart_W1 --> delete_watch_file
Although it would be a lot better to nail down the cause for your failures and get it resolved.

Glpi automatic action

I have a problem with an automatic action in GLPI, since the "Queuedmail", which is the action that sends the mail in queue every 1 minute according to my configuration, is not working, I do not know what to do, the only way to make it work is by manually executing it.
The version I use of GLPI is 9.1.6
This is very little information.
You need to check:
Quedmail Status: Is it set to Scheduled?
Quedmail Run mode:
If set to CLI you need to add a cron job (This is recommended). http://wiki.glpi-project.org/doku.php?id=en:config:crontab
Just for testing, change Run mode to GLPI. It would run based on anyones GLPi usage.
Regards,

How to trigger a build within a build chain after x days?

I am currently using Teamcity to deploy a web application to Azure Cloud Services. We typically deploy using powershell scripts to the Staging Slot and thereafter do a manual swap (Staging to Production) on the Azure Portal.
After the swap, we typically leave the Staging slot active with the old production deployment for a few days (in the event we need to revert/backout of the deployment) and thereafter delete it - this is a manual process.
I am looking to automate this process using Teamcity. My intended solution is to have a Teamcity build kick off x days after the deployment build has suceeded (The details of the build steps are irrelevant since I'd probably use powershell again to delete the staging slot)
This plan has pointed me to look into Teamcity build chains, snapshot dependencies etc.
What I have done so far is
correctly created the build chain by creating a snapshot dependency on the deployment build configuration and
created a Finish Build Trigger
At the moment, the current approach kickoffs the dependent build 'Delete Azure Staging Web' (B) immediately after the deployment build has succeeded. However, I would like this to be a delayed build after x days.
Looking at the above build chain, I would like the build B to run on 13-Aug-2016 at 7.31am (if x=3)
I have looked into the Schedule Trigger option as well, but am slightly lost as to how I can use it to achieve this. As far as I understand, using a cron expression will result in the build continuously running which is not what I want - I would like for the build B to only execute once.
Yes this can be done by making use of the REST api.
I've made a small sample which should convey the fundamental steps. This is a PowerShell script that will clear the triggers on another build configuration (determined by the parameter value in the script) and add a scheduled trigger with a start time X days on from the current time (determined by the parameter value in the script)
1) Add a PowerShell step to the main build, at the end and run add-scheduled-trigger as source code
2) Update the parameter values in the script
$BuildTypeId - This is the id of the configuration you want to add the trigger to
$NumberOfDays - This is the number of days ahead that you want to schedule the trigger for
There is admin / admin embedded in the script = Username / Password authentication for the REST api
One this is done you should see a scheduled trigger created / updated each time you build the first configuration
Hope this helps

How can I deploy code 'on-demand' using chef client-server architecture?

Here's the scenario:
I can SSH into my Chef-Server . But I can't SSH into any of the Chef-Clients. So this is how I work : I have a workstation to change or create Roles . All the chef-clients are running as daemons , so when they wake up , they notice state changes and start updating themselves .
Now , I need to configure code deployments on these clients . I was thinking I could use application cookbook for that , and add recipes to the roles using my workstation . But won't that result in deployments every time the chef-clients wake up and find revision changes ? I want an On Demand kind of deployment : I want to deploy only when the code is deployment ready , not for any other commit till that point .
How do I achieve this ?
Couple of questions
When id your code deployment ready? How would you know? If it's a repeatable process could you not code that into a recipe? if it's not a repeatable process you need to make it one so that it can be automated
IE run cucumber tests and if they all pass then deploy else just do nothing?
We feed from Artifactory and use the web api to check the latest installer available to us. If it's the same as previously installed (done by checking/creating a registry key) we say to the user, this build is already installed so we're skipping. If it's not the same we install. Now I know this isn't the exact same scenario but it feels to me like some custom code is going to be needed here.
Either that or leverage databag values to say install=true or false depending on the state of the code. You would update project a's install item in the databag when you want to deploy and the rest of the time it's set to false. The recipe would only proceed if the value was true?
Why not have a branch where HEAD is always ready to be deployed? Only push to this branch when your code is ready to go out into the world. Then you don't have to worry about intermediate, unstable states of your repository being synced by chef. Of course, you still have to wait for a client to wake up and sync before you see your changes, so if latency is a problem this won't work.

Jenkins-How to schedule a jenkins job when another job completes on remote machine

I have two remote machines: A and B. Both have Jenkins installed.
A: This will build from trunk.
B: To trigger automation.
How can I configure Jenkins job on Machine B, when the build is successful on Machine A?
I had the same requirement because one of the servers that I was using belonged to a different company and therefore, while it would be possible, it was clearly going to take a long time to get buy-in for me to alter their jenkins set-up, even though I was allowed access to monitor it and its outputs. However, if you don't have these restrictions, then you should definitely follow the whole master-slave configuration to address this. That said, here is a solution I came up with and just to note that I've explained why this was a genuine requirement, although I hope to go down the master-slave route myself when possible.
Install the ScriptTrigger plug-in for Jenkins and you can then watch the remote jenkins instance with a script similar to the following:
LAST_SUCCESSFUL_UPSTREAM_BUILD=`curl http://my.remote.jenkins.instance.com:8080/job/remoteJobName/lastSuccessfulBuild/buildNumber`
LAST_KNOWN_UPSTREAM_BUILD=`cat $WORKSPACE/../lastKnownUpstreamBuild || echo 0`
echo $LAST_SUCCESSFUL_UPSTREAM_BUILD> $WORKSPACE/../lastKnownUpstreamBuild
exit $(( $LAST_SUCCESSFUL_UPSTREAM_BUILD > $LAST_KNOWN_UPSTREAM_BUILD ))
Get the ScriptTrigger to schedule a build whenever the exit code is '1'. Set-up a suitable polling interval and there you have it.
This will obviously only schedule a build if the upstream job succeeds. Use "lastBuild" or "lastFailedBuild" instead of "lastSuccessfulBuild" in the URL above as your requirements dictate.
NOTE: Implemented using a BASH shell. May work in other UNIX shells, won't work in Windows.