ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From D Jayachandran <d.jayachand...@ericsson.com>
Subject RE: Plugin structure and specifications
Date Wed, 07 Jun 2017 12:29:13 GMT
Hi Ran,

Thanks for the information. I do agree with you on having plugin.yaml as part of plugin and
importing it to service template to have the plugin specific types.
Could you point me to some documentation involving these or any example of plugin.yaml


Regards,
DJ

-----Original Message-----
From: Ran Ziv [mailto:ran@gigaspaces.com] 
Sent: Tuesday, June 06, 2017 6:41 PM
To: dev@ariatosca.incubator.apache.org
Subject: Re: Plugin structure and specifications

? 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 <d.jayachandran@ericsson.com>
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
>
>
>
Mime
View raw message