Re: [openstack-dev] [Fuel][Plugins] Multi release packages

On Fri, Feb 12, 2016 at 11:47 AM, Evgeniy L 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

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

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

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

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

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

>> We have package format <=4.0 where all files have fixed names and locations. This is the defaults. The thing is for 5.0 there should be no default, those fields from now on should be specified explicitly. >> Igor want to provide multi-package I'm not familiar with this idea, could you please

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

Ilya, What do you mean by "default"? From the data format I see that we don't "override defaults" we specify the data for specific release, the way it was always done for deployment scripts and repositories. I don't see any reasons to complicate format even more and to have some things which are

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

Excuse me, i mean multi-release package. We already have release directives in plugin metadata.yaml that defines releases compatible with the plugin. As far as i understand "multi-release package" suppose ability to define custom configuration/code for each of this releases. On Fri, Feb 12, 2016

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

On Fri, Feb 12, 2016 at 2:03 PM, Evgeniy L wrote: > Ilya, > > What do you mean by "default"? From the data format I see that we don't > "override defaults" we specify the data for specific release, the way it > was always done for deployment scripts and repositories. > > We

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

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

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

r/YACL/YAQL/ On Thu, Feb 11, 2016 at 9:35 PM, Ilya Kutukov 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

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

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

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

Hi, On Thu, Feb 11, 2016 at 11:46 AM, Igor Kalnitsky 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

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

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

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

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

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

+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

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

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.

Re: [openstack-dev] [Fuel][Plugins] Multi release packages

On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko 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