Hi Vaish I agree. We should also consider the same idea for NFV and ONAP types (as opposed to make them built-in). I suspect those types may get updated without the need to update the ARIA orchestrator version.
Is it just a matter of allowing the admin user to load/delete type definitions files into the ARIA local host and specifying the repository option in the import definition? Similar to plugins? For instance: For individually managed plugins: -file : plugin.yaml repository: plugins For individually managed type definitions files: -file : typedefintion.yaml repository: definitions Regards Steve B -----Original Message----- From: Vaishnavi K.R [mailto:vaishnavi....@ericsson.com] Sent: Friday, November 10, 2017 6:30 AM To: dev@ariatosca.incubator.apache.org Subject: decoupling type definitions from CSAR Hi, With the current ARIA, in order to use the type definitions that are user defined, it must be imported in the Service Template. The definitions files are imported by specifying the relative paths in the 'imports' section. These type definition files can rather reside in the localhost running ARIA or can be made available by bundling along with the service templates in a CSAR. For remote executions, the latter holds good. However if the type definitions are so common and can be used across Service Templates, it becomes mandatory to include the same file in different CSARs. In order to reuse the type definitions that are common across service templates, it would be better to maintain the user defined type definitions separately and every service template can use it irrespective of their CSARs. This makes the user defined type definitions to be loaded once and the service templates could import it. I would like to know your view on this. Thanks, /Vaish
