Sorry for the typo "s/I can shade more light/I can shed more light/"
On Thu, Feb 11, 2016 at 1:51 PM, Evgeniy L <e...@mirantis.com> wrote: > Hi, > > As an author of this part of pluggable architecture I can shade more light > on why it was implemented this way and why it's valuable to continue > supporting multi-release feature. > > At the time it was implemented Fuel officially was supporting both Ubuntu > and CentOS, in order to simplify plugins distribution development and > support, > plugin developer was able to create a single plugin which supports both > operating systems, deployment scripts in the most cases support both > operating systems, if they are not, there is enough flexibility to specify > different set of deployment scripts and repositories. > > We don't force plugin developer to support all range of releases in a > single > plugin, it's up to plugin developer to decide what mechanism is better for > specific plugin, I'm strongly against of making "single release a.k.a os" > plugins. > > Also suggested change will dramatically complicate distribution when we > get heterogeneous environments (different operating system in a single > environment). > > Bulat is right that there are issues, but those issues has to be fixed, and > there is straightforward way to do it. > > To summarise, I don't think that we should force the developer to follow > specific release schema, let the developer decide. > > Thanks, > > > On Thu, Feb 11, 2016 at 10:16 AM, Bulat Gaifullin <bgaiful...@mirantis.com > > wrote: > >> I agree with Stas, one rpm - one version. >> >> But plugin builder allows to specify several releases as compatible. The >> deployment tasks and repositories can be specified per release, at the same >> time the deployment graph is one for all releases. >> Currently it looks like half-implemented feature. Can we drop this >> feature? or should we finish implementation of this feature. >> >> >> Regards, >> Bulat Gaifullin >> Mirantis Inc. >> >> >> >> On 11 Feb 2016, at 02:41, Andrew Woodward <xar...@gmail.com> wrote: >> >> >> >> On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko < >> dborodae...@mirantis.com> wrote: >> >>> +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. >>> >> >> Supporting multiple fuel releases will likely result in madness as >> discussed, however as we look to support multiple OpenStack releases from >> the same version of fuel, this methodology becomes much more important. >> >> >>> 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 < >>> 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 >>> > > >>> >> >> This will result in far too much clutter. >> For starters we should support nested over rides. for example the author >> may have already taken account for the changes between one openstack >> version to another. In this case they only should need to define the >> releases they support and not specify any additional locations. Later they >> may determine that they only need to replace packages, or one other file >> they should not be required to code every location for each release >> >> Also, at the same time we MUST clean up importing various yaml files. >> Specifically, tasks, volumes, node roles, and network roles. Requiring that >> they all be maintained in a single file doesn't scale, we don't require it >> for tasks.yaml in fuel library, and we should not require it in plugins. We >> should simply do the same thing as tasks.yaml in library, scan the subtree >> for specific file names and just merge them all together. (This has been >> expressed multiple times by people with larger plugins) >> >> > > 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://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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> -- >> >> -- >> >> Andrew Woodward >> >> Mirantis >> >> Fuel Community Ambassador >> >> Ceph Community >> __________________________________________________________________________ >> 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 >> >> >> >> __________________________________________________________________________ >> 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 >> >> >
__________________________________________________________________________ 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