ariatosca-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (ARIA-118) plugin.yaml importing
Date Mon, 04 Dec 2017 07:33:00 GMT


ASF GitHub Bot commented on ARIA-118:

djay87 opened a new pull request #212: ARIA-118 plugin.yaml importing
   This commit supports using the plugin.yaml present in a plugin wagon archive in a more
simpler way as described below.
     - file: <plugin_name>-<plugin_version>
       repository: plugins

This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

> plugin.yaml importing
> ---------------------
>                 Key: ARIA-118
>                 URL:
>             Project: AriaTosca
>          Issue Type: Story
>            Reporter: Ran Ziv
>            Assignee: D Jayachandran
>            Priority: Minor
>              Labels: plugins, wishlist
> 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

View raw message