Stanislaw B., You're somehow contradicting in your statements. However, taking into account your's -
> Both of these approaches can be used, so I'm against forcing plugin > developers to use just one approach. I can conclude that you support idea of having multi-release plugins? Because no one can restrict you use different VCS repos/branches for single release if you want to. Is that the case? - Igor On Fri, Feb 12, 2016 at 11:18 AM, Stanislaw Bogatkin <sbogat...@mirantis.com> wrote: >>>With plugins we extend Fuel capabilities, which supports multiple >>> operating system releases, so it's absolutely natural to extend multiple >>> releases at the same time. > It is okay for me when we talk about different operating system release, but > initial question was about different Fuel and OpenStack releases, it is not > the same. We can have one operating system thru several Fuel releases. > As I said - approach when you need extend plugin functionality to multiple > releases lead to mess in a plugin repo if you change the codebase from one > release to another. From other hand - it works wonderful if plugin codebase > doesn't change and all you need to support multiple Fuel releases is to > change metadata.yaml. Both of these approaches can be used, so I'm against > forcing plugin developers to use just one approach. > > On Fri, Feb 12, 2016 at 11:47 AM, Evgeniy L <e...@mirantis.com> wrote: >> >> Ilya, >> >> >> My opinion that i've seen no example of multiple software of plugins >> >> versions shipped in one package or other form of bundle. Its not a common >> >> practice. >> >> With plugins we extend Fuel capabilities, which supports multiple >> operating system releases, so it's absolutely natural to extend multiple >> releases at the same time. >> >> >> Anyway we need to provide ability to override paths in manifest >> >> (metadata.yaml). >> >> Could you please provide more information on that? I'm not sure if I >> understand your solution. >> >> Also I'm not sure what we are arguing about, if plugin developer (or >> certification process of some company) requires to have plugin per release, >> it's *very easy* and straight forward to do it even now *without any* >> changes. >> >> If plugin developer wants to deliver plugin for CentOS, Ubuntu, RH etc, >> let them do it, and again when we get full support of multi-version >> environments it's going to be even more crucial for UX to have a single >> plugin with multi-release support. >> >> Thanks, >> >> On Thu, Feb 11, 2016 at 9:35 PM, Ilya Kutukov <ikutu...@mirantis.com> >> wrote: >>> >>> My opinion that i've seen no example of multiple software of plugins >>> versions shipped in one package or other form of bundle. Its not a common >>> practice. >>> >>> Anyway we need to provide ability to override paths in manifest >>> (metadata.yaml). >>> >>> So the plugin developers could use this approaches to provide multiple >>> versions support: >>> >>> * tasks logic (do the plugin developers have access to current release >>> info?) >>> * hooks in pre-build process. Its not a big deal to preprocess source >>> folder to build different packages with scripts that adding or removing some >>> files or replacing some paths. >>> * and, perhaps, logic anchors with YACL or other DSL in tasks >>> dependancies if this functionality will be added this in theory could allow >>> to use or not to use some graph parts depending on release. >>> >>> I think its already better than nothing and more flexible than any >>> standardised approach. >>> >>> On Thu, Feb 11, 2016 at 6:31 PM, Simon Pasquier <spasqu...@mirantis.com> >>> wrote: >>>> >>>> Hi, >>>> >>>> On Thu, Feb 11, 2016 at 11:46 AM, Igor Kalnitsky >>>> <ikalnit...@mirantis.com> wrote: >>>>> >>>>> Hey folks, >>>>> >>>>> The original idea is to provide a way to build plugin that are >>>>> compatible with few releases. It makes sense to me, cause it looks >>>>> awful if you need to maintain different branches for different Fuel >>>>> releases and there's no difference in the sources. In that case, each >>>>> bugfix to deployment scripts requires: >>>>> >>>>> * backport bugfix to other branches (N backports) >>>>> * build new packages for supported releases (N builds) >>>>> * release new packages (N releases) >>>>> >>>>> It's somehow.. annoying. >>>> >>>> >>>> A big +1 on Igor's remark. I've already expressed it in another thread >>>> but it should be expected that plugin developers want to support 2 >>>> consecutive versions of Fuel for a given version of their plugin. >>>> That being said, I've never had issues to do it with the current plugin >>>> framework. Except when Fuel breaks the backward compatibility but it's >>>> another story... >>>> >>>> Simon >>>> >>>>> >>>>> >>>>> However, I starting agree that having all-in-one RPM when deployment >>>>> scripts are different, tasks are different, roles/volumes are >>>>> different, probably isn't a good idea. It basically means that your >>>>> sources are completely different, and that means you have different >>>>> implementations of the same plugin. In that case, in order to avoid >>>>> mess in source tree, it'd be better to separate such implementations >>>>> on VCS level. >>>>> >>>>> But I'd like to hear more opinion from plugin developers. >>>>> >>>>> - Igor >>>>> >>>>> On Thu, Feb 11, 2016 at 9: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://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 >>>>> >> >>>>> >> >>>>> >> >>>>> >> __________________________________________________________________________ >>>>> >> 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 >>>>> > >>>>> > -- >>>>> > >>>>> > -- >>>>> > >>>>> > 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 >>>> >>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> 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 >> > > > > -- > 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 > __________________________________________________________________________ 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
