-
Notifications
You must be signed in to change notification settings - Fork 27
Scheduleddelayed_launch_and_maximum_execution_time
I suppose that both delayed launch and maximum execution time settings are required on deployment level, not on individual instances level. Let me know if this is not true.
This covers 3 user scenarios:
- As a user I want to launch a deployment at specified time.
- As a user I want to launch a deployment at specified time repeatedly.
- As a user I want to specify maximum execution time for an instance
Dealyed_job can be used for this . It could work as follows:
-
a user sets launch time on a deployment launch page
-
after checking permissions , deployment+instances objects are created in conductor’s DB
-
we check if match is found at this point, if not, warning is displayed to user, but he is allowed to continue in delayed launch
-
launch request is queued in delayed_job queue with appropriate delay
-
delayed_job invokes launch request which: checks again permissions, finds a match and launches the deployment. If match is not found, deployment is not deleted but failed status is set both for deployment and instances.
Deployment model in conductor would be extended with attribute “launch_at”, this attribute would be set for delayed launches and would be displayed in UI. Deployments which are waiting for launch can be deleted, in such case delayed_job’s job should be removed from queue~~> another “job_id” attribute would be needed for keeping this id.
eg “launch this deployment every Monday at 7pm”. Scheduler is needed for this (well, we could re-enqueue bg job on each launch, but this is not optimal, more info is here: Background_Processing). If scheduler is integrated, then this is easy to implment - it’s almost same as “Launching deployments at specified time” but instead of queuing delayed job, scheduled job is created. This task requires more sophisticated UI for setting times of launching. This repetitive launching can be added in future (doesn’t have to be part of first cut).
Deployment model would be extended with attribute “execution_time”. There are two options how to handle this with current design:
-
for each running instance dbomatic checks if the instance’s deployment is set and if it reached execution time, if so, deployment stop action is called (on background)
-
deployment stop action is queued in delayed_job’s queue right after launching the deployment, delay for this job equals to execution time. I think this option is better.
TODO: measure execution time from when launch request was sent or from when deployment switched to running state? Running state is probably more useful.
eg. “stop this after 5 hours of running” vs. “stop this at 2012-06-24 20:00” Scheduled launch time would be set in absolute format. For execution time, both formats might be handy - for short-term times, relative format is better, for long-term times is better absolute format. For first cut, only absolute format might be supported. Can be extended in future. Time zone should be taken into account when setting time.
Deployment launch logic will be probably moved into separate component. So all the schedule/delay logic would be done by this component. A problem is that permissions checking and finding a match must be done right before launch request. So some special callback would be required. It could work as follows:
- after checking permissions (same as for common launching), deployment config is sent to the launch component which queues/schedules launch of this deployment at specified time
- at specified time launch component sends a callback back to conductor which finds a match for this deployement, checks again perms and replies back to launch component with found match
- launch component launches deployment with configuration returned from conductor