On Sun, May 25, 2014 at 4:18 AM, Sachith Withana <[email protected]>wrote:
> 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? > 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 <[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 > >
