Hi, We've come across an issue where one of users wants custom code compiled into one of our gateway apps. There are two areas of an app catalog that might be considered from that perspective: - can each gateway have its own app catalog to manage? - can the app catalog be designed so that a gateway user may be allowed to add apps to it? I think the original design had one app catalog for an Airavata deployment, shared by all gateways and only administrators would add or delete apps...
Kenneth On Wed, Jun 11, 2014 at 12:01:44PM -0700, K Yoshimoto wrote: > ----- Forwarded message from Sachith Withana <[email protected]> ----- > > Date: Sun, 13 Apr 2014 00:46:07 -0400 > From: Sachith Withana <[email protected]> > To: [email protected] > Subject: Re: Application Catalog Design > > Good questions and nice explanations by Eroma and Lahiru. Thanks for that. > > Are we going to allow multiple gateways to have the same application with > different deployments? > ex: gateway1 will have the ultrascan deployed in stampede and trestles > whereas gateway2 would have the same app deployed in stampede and lonestar. > > it boils down to whether we are going to support multiple gateways in the > Application Catalog Implementation or not. > > > > > On Thu, Apr 10, 2014 at 1:13 PM, Saminda Wijeratne <[email protected]>wrote: > > > A few jargon clarifications, > > > > > > - An application referred is theoretically an executable program or I > > suppose more precisely speaking a computational resource. (perhaps > > similar > > to a tool in CIPRES) > > - Application catalog would be essentially details of collection of > > applications which a gateway can query for, such that the gateway can > > submit jobs to any of the applications based on some input data and > > parameters. > > - A deployment is an instance of an application residing in a resource. > > Same executable program can be deployed in multiple locations, but since > > all those multiple deployments represent the same executable, we can > > consider all of them as just one application for the gateway which has > > being scaled. > > > > > > On Wed, Apr 9, 2014 at 9:52 PM, 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. > > > > > *globus --> global > > > > > > > > 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 > > >> > > > > > > > > > > > > -- > Thanks, > Sachith Withana > > ----- End forwarded message -----
