Thanks Ran, I will look into these. Regards, DJ
-----Original Message----- From: Ran Ziv [mailto:[email protected]] Sent: Wednesday, June 07, 2017 6:33 PM To: [email protected] Subject: Re: Plugin structure and specifications As I've mentioned on another thread, we're currently lacking much where it comes to documentation - we're working on updating the basic README file, but it'll probably be a while until there's going to be proper, comprehensive documentation. As for an example, ARIA currently has no plugins, so there's no direct example for this, however: 1) The "execution plugin" - whose name is somewhat inadequate as it's not quite a plugin, but rather built into the system - only uses the operation context API to execute operations. This can be used as an example for how to use ARIA's operation context API. 2) Cloudify has plugins whose code can be run on ARIA after installing a lightweight API adapter. This would make Cloudify plugins work on ARIA code-wise (Cloudify's plugins' "plugin.yaml" files are not written in TOSCA and as such won't work out of the box like so - but the Openstack plugin's "plugin.yaml" has been translated into TOSCA, and the AWS plugin's yaml is being translated at this time as well). This could be a good example for a "plugin.yaml" file in ARIA - but the code itself is not a good example for plugin implementation, as it uses Cloudify operation context API. See these resources: TOSCA Openstack plugin.yaml <https://github.com/cloudify-cosmo/cloudify-aria-extensions/blob/master/plugins/openstack/plugin.yaml> TOSCA Openstack hello-world example <https://github.com/cloudify-cosmo/cloudify-aria-extensions/blob/master/examples/hello-world/helloworld.yaml> making use of the Openstack plugin.yaml Cloudify extension repository <https://github.com/cloudify-cosmo/cloudify-aria-extensions> (where the operation context API adapter resides as well) Note that Cloudify plugins, as well as the adapter, are not part of ARIA, but merely additions that may be used by ARIA users if they desire so. Ideally, we'd like to have these plugins in ARIA using proper ARIA operation context API - But translating those at this time would mean not receiving updates from existing Cloudify plugins. Hope this helps, Ran On Wed, Jun 7, 2017 at 3:29 PM, D Jayachandran <[email protected]> wrote: > 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:[email protected]] > Sent: Tuesday, June 06, 2017 6:41 PM > To: [email protected] > 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 < > [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 > > > > > > >
