[jira] [Updated] (ARIA-118) plugin.yaml importing

["Ran Ziv (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ARIA-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ran Ziv updated ARIA-118:
-------------------------
    Description: 
Using a plugin currently requires a user first installs the plugin (using PluginManager), then import the relevant plugin.yaml file in the service template file. The import will currently likely point to a URL, or be a path relative to the service-template yaml file.

Some ideas for improvement and easing the import;
 - If a plugin contained its plugin.yaml as part of its wagon archive, then once installed, users could import the yaml file more easily using a notation such as {{plugins/openstack.yaml}} (or perhaps {{openstack.yaml}}, having the import mechanism iterate over plugins looking for this resource file or so)

 - The import mechanism could look for imports in the resource-storage as well - There could be a directory on the resource-storage designated for storing global yaml files for import, thereby simplifying reuse of yaml imports across service-templates.

 - Perhaps ARIA should also support importing yaml files by using paths relative to the service-template's package root (as opposed to only looking for paths relative to the current yaml file)? Note that this could lead to ambiguities in some cases.


Note that the last two don't necessarily have to do with plugins directly, but it's more likely to be relevant for plugins as they're used across service-templates more often.


  was:
Using a plugin currently requires a user first installs the plugin (using PluginManager), then import the relevant plugin.yaml file in the service template file. The import will currently likely point to a URL, or be a path relative to the service-template yaml file.

Some ideas for improvement and easing the import;
 - If a plugin contained its plugin.yaml as part of its wagon archive, then once installed, users could import the yaml file more easily using a notation such as {{plugins/openstack.yaml}} (or perhaps {{openstack.yaml}}, having the import mechanism iterate over plugins looking for this resource file or so)
 - The import mechanism could look for imports in the resource-storage as well - There could be a directory on the resource-storage designated for storing global yaml files for import, thereby simplifying reuse of yaml imports across service-templates.
 - Perhaps ARIA should also support importing yaml files by using paths relative to the service-template's package root (as opposed to only looking for paths relative to the current yaml file)? Note that this could lead to ambiguities in some cases.


Note that the last two don't necessarily have to do with plugins directly, but it's more likely to be relevant for plugins as they're used across service-templates more often.



> plugin.yaml importing
> ---------------------
>
>                 Key: ARIA-118
>                 URL: https://issues.apache.org/jira/browse/ARIA-118
>             Project: AriaTosca
>          Issue Type: Story
>            Reporter: Ran Ziv
>            Priority: Minor
>
> Using a plugin currently requires a user first installs the plugin (using PluginManager), then import the relevant plugin.yaml file in the service template file. The import will currently likely point to a URL, or be a path relative to the service-template yaml file.
> Some ideas for improvement and easing the import;
>  - If a plugin contained its plugin.yaml as part of its wagon archive, then once installed, users could import the yaml file more easily using a notation such as {{plugins/openstack.yaml}} (or perhaps {{openstack.yaml}}, having the import mechanism iterate over plugins looking for this resource file or so)
>  - The import mechanism could look for imports in the resource-storage as well - There could be a directory on the resource-storage designated for storing global yaml files for import, thereby simplifying reuse of yaml imports across service-templates.
>  - Perhaps ARIA should also support importing yaml files by using paths relative to the service-template's package root (as opposed to only looking for paths relative to the current yaml file)? Note that this could lead to ambiguities in some cases.
> Note that the last two don't necessarily have to do with plugins directly, but it's more likely to be relevant for plugins as they're used across service-templates more often.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)