Open Stack

+1 to Stas, supplanting VCS branches with code duplication is a path to
madness and despair. The dubious benefits of a cross-release backwards
compatible plugin binary are not worth the code and infra technical debt
that such approach would accrue over time.

On Wed, Feb 10, 2016 at 07:36:30PM +0300, Stanislaw Bogatkin wrote:
> 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.

> __________________________________________________________________________
> 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