-
Notifications
You must be signed in to change notification settings - Fork 0
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
Dealyedjob 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 delayedjob queue with appropriate delay
(delay = current time - launch time set by user)
# 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
“launchat”, 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
delayedjob’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 \
- 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 20120624
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