Change Cron Trigger life cycle

Registered by Renat Akhmerov on 2016-02-05

There's a problem in HEAT with healing functionality because:
* Heat recreates object if it has been deleted not via Heat but Cron Trigger gets deleted by Mistral if its "remaining_executions" reaches 0 so it shouldn't be recreated by Heat

Proposed solution:
* Never delete a cron trigger (even if it's remaining executions is 0)
* Remove "unique" constraint for cron trigger "name" field because otherwise usability will suffer (it's inconvenient to invent new names for cron triggers all the time)
* Have two fields for remaining executions: one means initial value and is immutable, another one is actual value meaning how many executions are left

Blueprint information

Status:
Not started
Approver:
Renat Akhmerov
Priority:
Undefined
Drafter:
Renat Akhmerov
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

While I am generally in favor of this - AFAIK this does not cause the described issue in Heat.

Heat will only recreate the resource after a stack-check was performed, the stack resource was changed to CHECK_FAILED and a stack-update is performed.

The Mistral Cron Trigger resource type does not implement the "handle_check" method which means that the logic of checking if the cron trigger exists is not there.
This means that the cron trigger stack resource will never go to CHECK_FAILED and will always be in CHECK_SUCCESS even if the cron trigger does not exist.

The fact that Heat does not create the cron trigger if it is missing can be considered as a bug and if that is fixed - this BP should be implemented.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.