airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <sma...@apache.org>
Subject Re: Versioning descriptors & workflows
Date Mon, 03 Sep 2012 00:04:06 GMT

On Sep 2, 2012, at 3:02 PM, Saminda Wijeratne <samindaw@gmail.com> wrote:

> There is no notion of versions at the moment for descriptors & workflows
> defined by gateway developers. Usefulness of such a feature would be that
> if a gateway developer updates a descriptor or a workflow and save as a new
> version, the users who are already using them for their own experiments
> need not have to update their stuff. How about we introduce it now itself
> so that further down the line we can give it as a useful feature?
> 
> Saminda

Hi Saminda,

I agree this is an important feature, but at same time I am not sure in the long term if Airavata
should heavy lift this burden and rather rely on versioning supported by registries. If just
adding a extra column to data base and exposing this through API will suffice for now, I am
+ 1 for this enhancement. I just want to caution loosing too much focus from Airavata core
functionality.

Some random thoughts on descriptor and workflow versioning:

* In general, workflows in development should be mutable, but once published should be immutable.

* If any one but the owner of the workflow/application service is creating a instance of a
application or workflow, they should be allowed to work against immutable definitions (application
or workflow). 
* There will be cases where some simple changes have to be made which can be safe without
side effects. How do we identify which changes are safe and will not effect non-cordinating
clients. 
* Consider this example: There is a template and multiple instances based on it have been
created. Now the template is changed or a new version is added because a serious bug is identified.
How should all running or waiting to run instances have to be notified? Is this a enactment
server problem or responsibility of a client to verify if a new version exists? 
* Consider some disruptive changes to workflow or application definition like: adding or removing
new inputs types or changing a type or changing a expression in a conditional construct. In
these cases, what will be a new version of workflow vs new workflow altogether?
* In general how do we minimize the co-ordination between client, server and registry in regards
to workflow/application versioning? 
* In the case of bug identified in a version and a subsequent workflow definition is deployed
and lets say the clients wants to make sure new version is used. So how do we identify based
on state of instances, which ones to need to be restarted, which ones need to be deleted,
how do we handle duplicates provenance data? 

Some of these problems are not related to registry per say and Airavata needs to be focusing
anyway, just listing these random thoughts for consideration.  

Cheers,
Suresh
Mime
View raw message