Shubham, When importing and you call registerApplicationModule, it returns the module id. Does that help?
Also you asked about computeHostId on Hipchat. I think computeHostId should be translated to the compute hostname when exporting because different Airavata instances will have different ids for the same compute host. You can use getAllComputeResourceNames to map from computeHostId to compute hostname when doing the export and you can use the same to do the reverse mapping on import. In general I don’t think we want any internal Airavata ids in the export JSON descriptor files since they will be unique to each Airavata instance. However, this does raise the issue of how can you tell if an application has already been imported? Perhaps there could be a check where when importing the CLI tool queries to see if an application module with the same name already exists and prompt the user whether to proceed or not. A more difficult problem here will be how to update an imported application, but we can tackle that later. Thanks, Marcus On Nov 14, 2017, at 6:53 PM, Shubham Kumar <[email protected]<mailto:[email protected]>> wrote: Hi Suresh, I am able to import Modules , Interfaces and Deployments in the new Gateway. But, all Deployments that are created in new gateway have Module name set to Abacus and compute resource as stampede. Module Id differs in between gateways. Not sure how to effectively search for moduleId in the list of newly created modules and then assign it to Deployment and Interface objects accordingly. Is above mentioned functionality sufficient for AppCatalog CLI tool to export AppCatalog Info ? Best, Shubham On Fri, Oct 13, 2017 at 3:04 PM, Shubham Kumar <[email protected]<mailto:[email protected]>> wrote: Hi all, For my assignment 4, I will continue working on CLI tool. JIRA Link - JIRA Issue<https://issues.apache.org/jira/browse/AIRAVATA-2559> In the Browse Application Modules page, the App Catalog section list all the Modules, Interface and Deployment used to create experiment on that Gateway Instance. Currently, all these details are either created or added manually. Goal is to automate this process by exporting these details into a JSON file which then can be imported into new installation. I was looking the details in dev.seagrid.org<http://dev.seagrid.org/>. But I assume all the list of modules , interface and deployment are also present on dev.testdrive.airavata.org<http://dev.testdrive.airavata.org/> . Please suggest any changes if you find something incorrect. Regards, Shubham Kumar
