Open Stack

It changes mostly nothing for case of furious plugin development when big
parts of code changed from one release to another.

You will have 6 different deployment_tasks directories and 30 a little bit
different files in root directory of plugin. Also you forgot about
repositories directory (+6 at least), pre_build hooks (also 6) and so on.
It will look as hell after just 3 years of development.

Also I can't imagine how to deal with plugin licensing if you have Apache
for liberty but BSD for mitaka release, for example.

Much easier way to develop a plugin is to keep it's source in VCS like Git
and just make a branches for every fuel release. It will give us
opportunity to not store a bunch of similar but a little bit different
files in repo. There is no reason to drag all different versions of code
for specific release.


On other hand there is a pros - your plugin can survive after upgrade if it
supports new release, no changes needed here.

On Wed, Feb 10, 2016 at 4:04 PM, Alexey Shtokolov <ashtokolov at mirantis.com>
wrote:

> Fuelers,
>
> We are discussing the idea to extend the multi release packages for
> plugins.
>
> Fuel plugin builder (FPB) can create one rpm-package for all supported
> releases (from metadata.yaml) but we can specify only deployment scripts
> and repositories per release.
>
> Current release definition (in metadata.yaml):
>     - os: ubuntu
>       version: liberty-8.0
>       mode: ['ha']
>       deployment_scripts_path: deployment_scripts/
>       repository_path: repositories/ubuntu
>
> So the idea [0] is to make releases fully configurable.
> Suggested changes for release definition (in metadata.yaml):
>       components_path: components_liberty.yaml
>       deployment_tasks_path: deployment_tasks_liberty/ # <- folder
>       environment_config_path: environment_config_liberty.yaml
>       network_roles_path: network_roles_liberty.yaml
>       node_roles_path: node_roles_liberty.yaml
>       volumes_path: volumes_liberty.yaml
>
> I see the issue: if we change anything for one release (e.g.
> deployment_task typo) revalidation is needed for all releases.
>
> Your Pros and cons please?
>
> [0] https://review.openstack.org/#/c/271417/
> ---
> WBR, Alexey Shtokolov
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
with best regards,
Stan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160210/01842e1a/attachment.html>