Thanks Saminda for the reply. Please refer to the inline comments
On Thu, May 22, 2014 at 10:25 AM, Saminda Wijeratne <[email protected]>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? > > - 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? > > - 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? > > > On Wed, May 21, 2014 at 1:15 AM, Sachith Withana <[email protected]>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
