airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mattmann, Chris A (388J)" <>
Subject Re: Airavata API review
Date Thu, 20 Dec 2012 05:30:40 GMT
Hey Guys,

On 12/19/12 6:08 PM, "Suresh Marru" <> wrote:

>I agree with Chris. My opinion is discussions should be discouraged but
>are ok to have as long as they are properly summarized and solicited for
>further comments on the mailing list. But *decisions* are certainly not
>acceptable. Lets please use mailing lists as much as possible for
>Hi Chris,
>Thanks for pointing this out, not to single out Chathuri here, but these
>discussions have been more prominent these days and lets all collectively
>avoid them. I will be more vigilant as well.

Thanks appreciate it, Suresh. Not singling out Chathuri -- it was a great
job to bring this discussion back on list, just pointing out that it's a
discussion until a decision is made here. Great work keep it up guys.


>On Dec 19, 2012, at 7:00 PM, "Mattmann, Chris A (388J)"
><> wrote:
>> Hi Guys,
>> One thing that concerns me about this thread is "offline discussions"
>> *things we decided upon*.
>> At Apache, all decisions happen on the mailing lists, so can you please
>> elaborate?
>> Cheers,
>> Chris
>> On 12/19/12 7:00 AM, "Chathuri Wimalasena" <> wrote:
>>> Hi Devs,
>>> We had some offline discussions regarding Airavata API and following
>>> some of the improvements that we decided on.
>>>  - *Change the name of AiravataManager in AiravataAPI interface*
>>>  - *Providing utility class for creating the ServiceDescriptor and all
>>>  the application creation (Look at the util class <DescriptorUtil>
>>> provided
>>>  in REST service).*
>>>  - *saveDeploymentDescription method should jus get a Host and Service
>>>  descriptor objects rather passing the names.*
>>>  - Instead of having single save method for both add and update, we
>>>  should have separate methods for those functionalities
>>>  - *Remove isExist check from the save methods, ideally when we
>>> introduce
>>>  above add and update functions separately, this will become obsolete.*
>>>  - *Use ApplicationDescriptor in all the places.*
>>>  - *Overload saveWorkflow function and pass the URI of a workflow
>>>  - *Add the method - getWorkflowTemplateIds in integration tests.*
>>>  - *Adding tests for workflow metadata saving in integration test.*
>>>  - *We need fill up all the arguments in runExperiment method to show
>>> the
>>>  users how they are suppose to use the method.*
>>>  - *Adding tests for querying by Experiment name.*
>>>  - *Add tests for all the runExperiment overloaded methods.*
>>>  - *Put API comments for runExperiment and other methods.*
>>>  - *For the test case we need implement the pulling and pushing the
>>>  status of the workflow. Pulling from registry and get the pull
>>>  from notification.*
>>>  - *Add a stopMonitoring function to ExecutionManager*
>>>  - *Improvements to runExperiment() method
>>>  *
>>>     - we need to get rid of all 6 overloaded methods
>>>        - keeping the simple one as it is and passing a bean object for
>>>        advance cases
>>>        - giving different names for method signatures if the usage for
>>>        the API user is different
>>>        - having fine grained exception types
>>>     - ContextHeaderBuilder
>>>        - revamp the schema
>>>        - get rid of unused parameters in ContextHeaderBuilder class
>>>        - instead of having single ContextHeaderBuilder class, have
>>>        different classes according to usage
>>>           - scheduling
>>>           - output handling
>>>           - security
>>> Plan is to do all the suggested improvements before 0.6 release except
>>> security section of ContextHeaderBuilder class improvement.
>>> All your feedback is most welcome.
>>> Thanks and Regards,
>>> Chathuri

View raw message