Idea #2352
closedPipeline instance state is represented with a state machine instead of "active" and "success" flags
Description
- User can interrupt/continue pipelines
- User can run pipeline from command line and doesn't conflict with crunch-dispatch
active
and success
booleans. The only tricky bit is keeping things working during transition. This might work:
- add the
state
attribute (string) -- update all existing records to suitable state during the migration - override
active
andsuccess
methods to return appropriate values based on current state - remove the
active
andsuccess
booleans from the database - override update_attributes so if someone tries to update "active" or "success", the new "state" gets changed instead
- fix clients so they read/update
state
instead of reading/updatingactive
andsuccess
- some weeks later: remove the
active
andsuccess
methods and remove from the api response
Updated by Tom Clegg over 10 years ago
- Target version set to 2014-04-16 Dev tools and data/resource management
Updated by Peter Amstutz over 10 years ago
- Subject changed from User can stop and restart a pipeline that is being run by crunch-dispatch. to Pipelines status is represented with a state machine
- User can interrupt/continue pipelines
- User can run pipeline from command line and doesn't conflict with crunch-dispatch
Updated by Peter Amstutz over 10 years ago
- Assigned To changed from Peter Amstutz to Radhika Chippada
Updated by Tom Clegg over 10 years ago
- Subject changed from Pipelines status is represented with a state machine to Pipeline instance state is represented with a state machine instead of "active" and "success" flags
Updated by Tom Clegg over 10 years ago
- Description updated (diff)
- New
- Ready
- RunningOnServer
- RunningOnClient
- Paused
- Failed
- Complete
- Add a components_summary attribute to PipelineInstance -- similar to tasks_summary in Job
{ "failed": 0, "todo": 4, "running": 1, "done": 1 }
Updated by Tom Clegg over 10 years ago
- crunch_dispatch should look for
state=RunningOnServer
(instead of active=true) when deciding which pipeline instances it should be trying to run - Workbench pipeline instance
index
andshow
pages should look atstate
instead of active/complete flags when deciding what label to put on each pipeline instance - Workbench pipeline instance "specify inputs and start" page (
show
?) should only enable the "start" button only ifstate
isReady
orPaused
-- and should only show the "choose inputs" page ifstate=New
orstate=Ready
- arv-run-pipeline-instance should set
state=New
when creating a pipeline instance - arv-run-pipeline-instance should set
state=RunningOnClient
if--run-here
is used andarv-run-pipeline-instance
is in fact still running - arv-run-pipeline-instance should set
state=Paused
before exiting, if--run-here
is used (unless of coursestate=Failed
orComplete
by that point) - arv-run-pipeline-instance should set
state=RunningOnServer
if--run-on-server
was used - API server should change from "New" to "Ready" when a pipeline instance is created or updated, if all required parameters are provided (unfortunately this duplicates some of the "ready to run?" logic from arv-run-pipeline-instance, for now)
Updated by Tom Clegg over 10 years ago
- Target version changed from 2014-04-16 Dev tools and data/resource management to 2014-05-07 Storing and Organizing Data
Updated by Radhika Chippada over 10 years ago
- Story points changed from 2.0 to 3.0
Updated by Tom Clegg over 10 years ago
is_ready
should be an instance method, and operate on the instance's own components. Could also call itcomponents_look_ready?
(might be more clear that it doesn't just teststate==Ready
or something like that). Then:- if PipelineInstance.is_ready pi.components + if pi.components_look_ready?
- Perhaps if there are no components,
components_look_ready?
should returnfalse
-- seems likestate
should probably stay atNew
instead ofReady
in this case. - Is there a reason to accept
"false"
,"0"
, etc. as false? I prefer to expectrequired
to be a genuinefalse
. (This seems like a bad hole to start digging. If we really must have a list of values that are false, we should at least use the same list throughout the application. But I'd be more inclined to go with "ifrequired
is something other than true or false, the component is not correctly specified and therefore never considered ready, so we refuse to switch toRunningOnServer
orReady
.") - In tests,
{"required" => "true"}
should probably be{"required" => true}
unless you're deliberately testing "other values that evaluate to true" behavior. - Should test
{"required" => false}
- Maybe add a little comment to the migration
=begin
/=end
blocks to explain why they're commented out. - In
elsif state_changed?
block- This is probably the part that will remain after we get rid of vestiges of
success
andactive
- Do something for
Paused
- Fail validation if someone updates to
state="bogus"
- This is probably the part that will remain after we get rid of vestiges of
Updated by Tom Clegg over 10 years ago
sdk/cli/bin/arv-run-pipeline-instance
→ if $options[:submit]
- Should set
:state => 'RunningOnClient'
here?
services/api/app/models/pipeline_instance.rb
→ verify_status
- I think we should automatically state to "Ready" if the client sets/changes state to "New" but the components look ready? (If I'm reading it correctly, as it stands the client could create a new instance with components that look ready and set state to New, but the server would not admit that it thinks the instance is Ready until the client saves it again with different components or state. Perhaps change the last "elsif" to a distinct "if" block?)
Updated by Tom Clegg over 10 years ago
Oh, and update PipelineInstance.queue to look for state = 'RunningOnClient'
instead of active = true
:
def self.queue self.where('active = true') end
...then crunch-dispatch will leave RunningOnClient pipeline instances alone.
Updated by Ward Vandewege over 10 years ago
- Target version changed from 2014-05-07 Storing and Organizing Data to 2014-05-28 Pipeline Factory
Updated by Tom Clegg over 10 years ago
@ eff3277
Hm. What I wrote above doesn't make sense -- I should have said RunningOnServer, right? So instead of
self.where("active = true or state = 'RunningOnClient'")
we should have
self.where("state = ?", RunningOnServer)
(PipelineInstance.queue is only used by crunch_dispatch so it should only return RunningOnServer, not RunningOnClient -- and active=true is not necessary to check any more now that we have "state" -- right?)
Everything else looks good.
Updated by Tom Clegg over 10 years ago
@ faf355b
If you start a pipeline, then stop it, it goes to "Paused" state, right? In that case I think this should use editable:true
for either @object.state=='New' or @object.state=='Ready'
+ <% if @object.state == 'New' %> + <%= render partial: 'show_components_editable', locals: {editable: true} %> + <% else %> + <%= render partial: 'show_components_editable', locals: {editable: false} %> + <% end %>
Remove obsolete code instead of leaving it commented out (we always have git history if we want them back):
- @instance[:active] = moretodo +# @instance[:active] = moretodo
In the "cleanup" function I think the main thing is to prevent "says RunningOnClient but in fact the client has stopped", so instead of
if @instance # @instance[:active] = false @instance[:state] = 'New' # should it be Failed? @instance.save end
maybe just
if @instance and @instance[:state] == 'RunningOnClient' @instance[:state] = 'Paused' @instance.save end
(If the instance is in any other state when a-r-p-i crashes or gets ^C, it should probably be left alone.)
Things sure do look better with "state==X" than with "active && !success" etc.!
Updated by Radhika Chippada over 10 years ago
- Status changed from In Progress to Resolved
This had been a very interesting story to work on. I am pleased with what had been accomplished in this story.