airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sachith Withana <swsach...@gmail.com>
Subject Re: Application Catalog CPI design
Date Tue, 27 May 2014 09:29:58 GMT
So from what we discussed both offline and in this thread, these are the
changes I propose to the current design,


   1. Application Object will be passed as a whole to the GFac so that it
   can deal with it. ( It does not include deployment specific information)
   2. Those Application Objects would be cached ( minimize the data
   retrieval overhead)
   3. When the GFac wants to get the deployments for a particular
   application, the CPI would provide a method that looks like
   getDeployments( String appcalitionID, HashMap filters), the hashmap
   would contain the filters that Gfac wants to filter application deployments
   with,
   ex: get deployments for the application that involves trestles or
   stampede

   This would prevent the Gfac having to go through the deployments and
   filtering them out.


WDYT?



On Tue, May 27, 2014 at 8:58 AM, Saminda Wijeratne <samindaw@gmail.com>wrote:

>
>
>
> On Sun, May 25, 2014 at 4:18 AM, Sachith Withana <swsachith@gmail.com>wrote:
>
>> Thanks Saminda for the reply.
>> Please refer to the inline comments
>>
>>
>> On Thu, May 22, 2014 at 10:25 AM, Saminda Wijeratne <samindaw@gmail.com>wrote:
>>
>>> Looking what generally GFac requires I'd say something along the lines
>>> of following would be useful.
>>>
>>>    - Functions required to retrieve all the access data of a given
>>>    application id (eg: inputs/outputs/security data/validation data/host
>>>    properties/application properties/job properties etc.)
>>>
>>> We can just return the whole Application Object which contains all these
>> details right? Since Gfac would be getting all these data at the same time,
>> it would be a better option to minimize the calls between the Gfac and the
>> App catalog and just return the object?
>>
> It would make sense to do so if GFac wants everything related to that
> application. But IMO at launch GFac will not need any user metadata,
> description fields, validation data (if validation done at orchestrator
> already), alias info, irrelevant deployment data etc.
>
>>
>>
>>>
>>>    - Functions to help gfac scheduling (eg: get all SSH supported
>>>    deployments, get all trestles deployments)
>>>
>>> Thanks for pointing this out Saminda. But I failed to understand the use
>> case here?
>>
> eg: GFac will have its own criteria to filter-out and select the
> deployment its going to use.  However IMO we can provide basic filtration
> through App Catalog CPI to only send through a filtered set of deployments
> so that GFac doesn't have to deal with all the deployments of an
> application. Saves db query time, network turnaround time and memory usage.
>
>>
>>
>>>
>>>    - Functions validating permissions to use the resources (eg:
>>>    disabled resources, inactive job managers etc)
>>>
>>> Do you mind elaborating the line above? Disabled resources on what
>> level? from the gateway level or the Airavata level?
>>
> This can be one of the functions provided by App Catalog CPI. But gateways
> might be interested in managing these information themselves and during
> experiment creation would imply such permission information. Disabled
> resources can be drilled down to application, deployment, host. Like I
> mentioned above it could be at the gateway side if gateway wants to manage
> it. In which case AppCatalog do not have to worry about it.
>
>>
>>
>>>
>>>
>>> On Wed, May 21, 2014 at 1:15 AM, Sachith Withana <swsachith@gmail.com>wrote:
>>>
>>>> Hi folks,
>>>>
>>>> Here's[1] the initial Application Catalog Design with the basic
>>>> functions regarding the application, deployment, host and gatewayProfile
>>>> Objects.
>>>>
>>>> In terms of the users of the App Catalog like the GFac, what kind of
>>>> fine-grained CPI methods are required ?
>>>>
>>>> ex: should we pass the whole Application Object and expect the GFac to
>>>> deal with it or allow more fine-grained methods to get the inputs, hosts
>>>> ...etc?
>>>>
>>>> Please note that I haven't included the search functionality in this
>>>> phase of the CPI design.
>>>>
>>>>
>>>> [1]
>>>> https://docs.google.com/document/d/1FfAT0kRFUJR78o9Pj58sNcUJJzPTojmD3zjldiWfIik/edit
>>>>
>>>> --
>>>> Thanks,
>>>> Sachith Withana
>>>>
>>>>
>>>
>>
>>
>> --
>> Thanks,
>>  Sachith Withana
>>
>>
>


-- 
Thanks,
Sachith Withana

Mime
View raw message