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 <ashtoko...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- with best regards, Stan.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
