? Do we have any specifications on the structure of plugin ? --> A plugin should simply be a standard Python package really; There are no special constraints on its structure. If the plugin has dependencies, they do need to be compatible with ARIA's, as the plugin's code will be loaded in the same environment as the ARIA code which loads it; However, one plugin's dependencies do not need to be compatible with another plugin's dependencies - those are completely isolated from one another thanks to the PluginManager class. Also see this related jira issue <https://issues.apache.org/jira/browse/ARIA-247>, which could be taken into consideration when deciding about the plugin's structure - although note that the notation/syntax used in the "implementation" field might change at some point to not be in "Python syntax".
? With the current state, a plugin can be referenced in different node types. ? Can a plugin also contain node types specific to its implementation ? If we can associate a plugin to specific node types there will not be need to import the node types in our service template every time. We think bundling node types as part of plugin and having them available to those service templates using the plugins would be a good option. Do you have any suggestions regarding this ? Do you already have something on this in your roadmap ? --> The plugin mechanism is a means of delivering code into ARIA. You can have a "plugin.yaml" file to import manually from your service-template, where that file is coupled with operations (and a policy definition) of a specific plugin. There is also a jira issue <https://issues.apache.org/jira/browse/ARIA-118> about how this coupling might be made somewhat simpler. However, I do not think that having the plugin "auto-import" the node type definitions is a good idea: First, it's not standard TOSCA - All yaml imports must be declared explicitly. Second, instead of being forced to declare the import, you'd be forced to declare the plugin policy (otherwise how would the parser know which "plugin.yaml" files to import for your service-template? I think the case where the user simply defines a single import "openstack" and automatically receives the ability to refer to types from the openstack plugin's "plugin.yaml" etc. is the way to go here. Ran On Tue, Jun 6, 2017 at 8:42 AM, D Jayachandran <[email protected]> wrote: > Hi, > > ARIA currently supports plugin based lifecycle operation. A plugin here > refers to a python module packaged as a wagon archive. > I have few queries on how the plugin is being seen at this moment > > > ? Do we have any specifications on the structure of plugin ? > > ? With the current state, a plugin can be referenced in different node > types. > > ? Can a plugin also contain node types specific to its implementation ? If > we can associate a plugin to specific node types there will not be need to > import the node types in our service template every time. > > We think bundling node types as part of plugin and having them available > to those service templates using the plugins would be a good option. Do you > have any suggestions regarding this ? Do you already have something on this > in your roadmap ? > > > Regards, > DJ > > >
