In Self-Service, using CAT code to run workflow during operations like stop, start, but also creating custom workflows for backups, etc., has been a real nice feature.
In my case, we execute specific tasks, such as shutting down a stack of applications, clean-up cache and/or take a backup.
If any task or API call fails, it puts the CloudApp in a failed state, where an end-user is lacking privileges to see the "force to stopped/running". Depending on what task failed, considering a lot of our users are responsible for their own application stack, (developers, technical support, etc.), we want them to be able to continue to operate the CloudApp without intervention.
I had been looking for a way to, in stead of failing (raise "condition") the CloudApp, to just put it back into a running state - while providing the user with the appropriate warning information.
Although Self-Service does not have a method to abort an operation, it does offer a method to just run the start operation again. In my specific case, the start operation will check to see if the instance(s) are already operational - it will be a no-op at that point.
...
else # prior step during shutdown operations failed
$time = now() + 30
rs_ss.scheduled_actions.create(
execution_id: @@execution.id,
action: "start",
first_occurrence: $time
)
Besides the putting the app back in Running, based on the information returned from the prior steps, I assign a message to an output variable that is displayed in the Info tab for the CloudApp.
I hope sharing this tidbit helps other people!
Nov 04, 2019 10:28 AM
@averharen Are you using subroutines? If so, you can use the `on_error` attribute to catch the error and skip or do something else.
https://docs.rightscale.com/ss/reference/rcl/v2/index.html#attributes-and-error-handling-errors-and-error-handling
Feb 07, 2020 02:56 PM
Hi @spomeroy ,
I really don't have a solution for this issue. What I described doesn't even work, because the action fails due to the CloudApp being in a failed state.
1. The user needs to get a notice that something went wrong, and a failed cloudApp does that. I've made sure to include relevant messaging. Sure, I can ignore the error, but that's not what I want - the owner(s) need to understand there was a problem.
2. The user doesn't have the ability to address it, because the app is in a FAILED state. It now requires an admin.
People launching CloudApps should have the ability to put it back in Running state, but they don't have that privilege.
What's the privilege needed for the user to be able to put it back into a Running state?
If I make the user admin, they can see everyone's CloudApps, I don't want that.
Thanks if you have any better suggestions!
Mar 03, 2020 07:59 PM