On Fri, Feb 12, 2016 at 11:47 AM, Evgeniy L <[email protected]> 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. > > I just warning against idea when to merge content of several plugin distributions in one bundle. But it's ok for plugin code to support multiple releases one or another way. > >> 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. > > https://review.openstack.org/#/c/271417/5/specs/9.0/plugins-v5.rst L150 and further We are overriding default path with special per-release path attributes. The question is to use per-release way described in spec or don't bother and specify this overrides only in metadata.yaml root. > 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 <[email protected]> > 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 <[email protected]> >> wrote: >> >>> Hi, >>> >>> On Thu, Feb 11, 2016 at 11:46 AM, Igor Kalnitsky < >>> [email protected]> 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 >>>> <[email protected]> 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 <[email protected]> wrote: >>>> > >>>> > >>>> > >>>> > On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko < >>>> [email protected]> >>>> > 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 >>>> >> > <[email protected]> >>>> >> > 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: >>>> >> > > [email protected]?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: >>>> >> > [email protected]?subject:unsubscribe >>>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >> >>>> >> >>>> >> >>>> __________________________________________________________________________ >>>> >> OpenStack Development Mailing List (not for usage questions) >>>> >> Unsubscribe: >>>> [email protected]?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: >>>> [email protected]?subject:unsubscribe >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> > >>>> > >>>> > >>>> > >>>> __________________________________________________________________________ >>>> > OpenStack Development Mailing List (not for usage questions) >>>> > Unsubscribe: >>>> [email protected]?subject:unsubscribe >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> > >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
