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/Scheduledd...
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/