Hi, Few things that came to my mind, 1. Can we extend current registry to act as an application catalog ? 2. How are we going to enter application details into the catalog? Is it done by a gateway ADMIN or a Airavata ADMIN? IF a gateway has a front-end to do this are we allowing it? With CIG how it would be? 3. Are we going to allow an application deployment in a resource to have a state such as ACTIVE/INACTIVE? 4. Will there be a default resource for an application? e.g.: For Ultrascan default resource for ECHO application is Stampede 5. Are we going to allow gateways to manage/maintain their application catalog? 6. Are we going to store only metadata related to applications or are we going to store output results from experiments also ? 7. Does application catalog need to stores credentials for resources ?
Thank You, Best Regards, Eroma On Thu, Apr 10, 2014 at 12:52 AM, Saminda Wijeratne <[email protected]>wrote: > Hi Sachith, > > Please find my comments inline > > > On Tue, Apr 8, 2014 at 10:35 AM, Sachith Withana <[email protected] > >wrote: > > > Hi all, > > > > This is regarding the issue > > Airavata-1126<https://issues.apache.org/jira/browse/AIRAVATA-1126> > > . > > > > I have a few questions regarding the design. > > > > 1. Is the Application Catalog going to be queryable? > > > Currently we do not have an advance usecase which requires gateway users > needing to query for application definitions or their deployments out of > application catalog. But there might be a scenario which gateway users > might be interested in selecting deployments based on their static > configurations and/or dynamic status. For example "allow execution in an > clustered resource which is currently not that busy or capable of finishing > the job within 48 hours". We see in Ultrascan, users are given the choice > to select the cluster of which they can run their simulation. > On the other hand querying could be very useful for scheduling purposes. > Thus it is useful feature for Airavata core developers and in rare > scenarios gateway developers also. > > 2. How are you going to handle the multiple deployments of an application? > > going to be multiple Application catalog for each deployment or one > App > > catalog for each deployment describing where the application is deployed? > > > Current offline discussions we had points to having one globus application > catalog shared among gateways. Since we still do not have a specific design > for this, I'll put forward my general thoughts about the application > catalog. > > 1. Single deployment of Airavata will have only one application catalog > shared among any registered gateways in that Airavata instance. > 2. An application catalog will contain multiple applications and each > application may have multiple deployments defined for it. > 3. Permissions are placed to control which applications are available to > which gateway (Airavata admin will configure this) > 1. Gateways can list all applications in the application catalog but > they can only access the ones which they have permission > 2. permission could be defined for different deployments of the same > applications > 4. Given an application in the application catalog the access data > and metadata could be considered in to 2 categories which 1) shared 2) > gateway specific. (its still a question where we save gateway specific > data) > 5. Gateways can request deployment details of an application which it > has permission to. > 6. Airavata admins can add/remove applications and its deployments, > enable/disable permissions for resources defined in the application > catalog > for gateways, activate/deactivate resources defined in application > catalog > for gateway(s) for a period of time or permanently etc. > > I'm working on a mindmap to gather all the data relating to an application > catalog. I will post it to the list once I have a decent looking one. > > Question I do have in my mind is where should the resources such as > resource paths defined. Whether it should be part of the application access > data or should be independent and later linked to application access data? > The reason is if we are planning to allow GFac to handle file management > Tasks in future it might be easier to separating out resource paths from > application access data. wdyt? > > > > > -- > > Thanks, > > Sachith Withana > > > -- Thank You, Best Regards, Eroma
