RFC - Delayed Launch

Mike Orazi morazi at redhat.com
Tue Jan 15 19:51:41 UTC 2013


On 01/14/2013 10:55 PM, Brian McLaughlin wrote:
> I'm in the process of implementing the first user story, Delayed Launch,
> per the Redmine page below [1]. I've pulled out the relevant section of
> the page for quick reference below.  I'm also adding what views I
> believe will be edited along the way.  I figure soliciting comments and
> suggestions before getting too far is a good idea...
>
> ---
>
> User Story:
> 1. As a user I want to launch a deployment at a specified time.
>
> Delayed_job can be used for this (we already have it integrated). It
> could work as follows:
> 1. a user sets launch time on a deployment launch page
> 2. after checking permissions (same as for common launching),
> deployment+instances objects are created in conductor's DB (both
> deployment and instances stay in 'NEW' state)
> 3. 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
> 4. launch request is queued in delayed_job queue with appropriate delay
> (delay = current time - launch time set by user)
> 5. 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.
>
> Deployments which are waiting for launch can have their launch time
> edited.  One of two scenario's would occur then:
> 1. Update the delay of the job in the queue of delayed_job
> 2. Duplicate the request currently queued in delayed_job, issue a new
> request to delayed_job and delete the original request.
> Both of these scenarios would also require a "job_id" attribute be
> created to keep the delayed_job id.
>
>
>
> Views
> - src/app/views/deployments/_launch_new.html.haml
> - src/app/views/deployments/launch_time_params.html.haml
> - src/app/views/deployments/_deployment_card_index.html.mustache
> - src/app/views/deployments/show.html.haml
> - src/app/views/instances/_instance_card.html.mustache
> - src/app/views/deployments/_edit.html.haml
>
>
> [1]
> https://redmine.aeolusproject.org/redmine/projects/aeolus/wiki/Scheduleddelayed_launch_and_maximum_execution_time
>

Without looking at the content too much, this looks like it probably 
ought to wind up on the github wiki[1].  Once the story has been 
detailed enough, it likely should wind up as at least an issue in github 
issues[2], perhaps multiple depending on how you break up the work.

You could run the raw textile through pandoc[3] to get markdown (the 
markup that folks are using on the new wiki).  Alternately, Mo might 
have a suggestion for a better toolchain to get this moved over or you 
could just do it by hand.

Let me know if you need a hand and I'll see what I can do.

Thanks in advance,
Mike

[1] https://github.com/aeolusproject/conductor/wiki
[2] https://github.com/aeolusproject/conductor/issues?state=open
[3] http://johnmacfarlane.net/pandoc/



More information about the aeolus-devel mailing list