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

[Ilya Kutukov]

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

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

[Stanislaw Bogatkin]

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

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

[Igor Kalnitsky]

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

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

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

[Evgeniy L]

>> 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 clarify what
multi-package is?

Thanks,

On Fri, Feb 12, 2016 at 2:57 PM, Ilya Kutukov  wrote:

>
>
> 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 have package format <=4.0 where all files have fixed names and
> locations. This is the defaults.
>
> 1. The maintenance team wants ability to specify folder instead plugin
> configuration files so there should be ability to change this paths to
> define a folder or other non-standard location. Yes, plugin developer could
> have whatever source structure and then translate it to the file structure
> required for the FPB with scripts or build system, but ability to split
> e.g. tasks files looks useful for me.
>
> 2. Igor want to provide multi-package, so, according to spec, this custom
> release-specific paths to other package files could be specified in release
> records.
>
> I don't see any reasons to complicate format even more and to have some
>> things which are related to the deployment specified in the root and some
>> in specific release.
>>
>> There is consistent mechanism to specify such kind of things, lets just
>> use it.
>>
>> Thanks,
>>
>> On Fri, Feb 12, 2016 at 1:24 PM, Ilya Kutukov 
>> wrote:
>>
>>>
>>>
>>> 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 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 
 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, 

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

[Evgeniy L]

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 related to the deployment specified in the root and some
in specific release.

There is consistent mechanism to specify such kind of things, lets just use
it.

Thanks,

On Fri, Feb 12, 2016 at 1:24 PM, Ilya Kutukov  wrote:

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

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

[Ilya Kutukov]

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 at 3:19 PM, Evgeniy L  wrote:

> >> 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 clarify what
> multi-package is?
>
> Thanks,
>
> On Fri, Feb 12, 2016 at 2:57 PM, Ilya Kutukov 
> wrote:
>
>>
>>
>> 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 have package format <=4.0 where all files have fixed names and
>> locations. This is the defaults.
>>
>> 1. The maintenance team wants ability to specify folder instead plugin
>> configuration files so there should be ability to change this paths to
>> define a folder or other non-standard location. Yes, plugin developer could
>> have whatever source structure and then translate it to the file structure
>> required for the FPB with scripts or build system, but ability to split
>> e.g. tasks files looks useful for me.
>>
>> 2. Igor want to provide multi-package, so, according to spec, this custom
>> release-specific paths to other package files could be specified in release
>> records.
>>
>> I don't see any reasons to complicate format even more and to have some
>>> things which are related to the deployment specified in the root and some
>>> in specific release.
>>>
>>> There is consistent mechanism to specify such kind of things, lets just
>>> use it.
>>>
>>> Thanks,
>>>
>>> On Fri, Feb 12, 2016 at 1:24 PM, Ilya Kutukov 
>>> wrote:
>>>


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

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

[Ilya Kutukov]

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 have package format <=4.0 where all files have fixed names and
locations. This is the defaults.

1. The maintenance team wants ability to specify folder instead plugin
configuration files so there should be ability to change this paths to
define a folder or other non-standard location. Yes, plugin developer could
have whatever source structure and then translate it to the file structure
required for the FPB with scripts or build system, but ability to split
e.g. tasks files looks useful for me.

2. Igor want to provide multi-package, so, according to spec, this custom
release-specific paths to other package files could be specified in release
records.

I don't see any reasons to complicate format even more and to have some
> things which are related to the deployment specified in the root and some
> in specific release.
>
> There is consistent mechanism to specify such kind of things, lets just
> use it.
>
> Thanks,
>
> On Fri, Feb 12, 2016 at 1:24 PM, Ilya Kutukov 
> wrote:
>
>>
>>
>> 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 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 
>>> 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  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 

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

[Evgeniy L]

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  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 
> wrote:
>
>> 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 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
>>>  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  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.
>>> >

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

[Ilya Kutukov]

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

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

[Evgeniy L]

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

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

[Simon Pasquier]

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

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

[Ilya Kutukov]

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

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

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

[Stanislaw Bogatkin]

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

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

[Dmitry Borodaenko]

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

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

[Bulat Gaifullin]

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

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

[Alexey Shtokolov]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Andrew Woodward]

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