<div dir="ltr">Hi,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 11, 2016 at 11:46 AM, Igor Kalnitsky <span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey folks,<br>
<br>
The original idea is to provide a way to build plugin that are<br>
compatible with few releases. It makes sense to me, cause it looks<br>
awful if you need to maintain different branches for different Fuel<br>
releases and there's no difference in the sources. In that case, each<br>
bugfix to deployment scripts requires:<br>
<br>
* backport bugfix to other branches (N backports)<br>
* build new packages for supported releases (N builds)<br>
* release new packages (N releases)<br>
<br>
It's somehow.. annoying.<br></blockquote><div><br></div><div>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.<br></div><div>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...<br><br></div><div>Simon<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
However, I starting agree that having all-in-one RPM when deployment<br>
scripts are different, tasks are different, roles/volumes are<br>
different, probably isn't a good idea. It basically means that your<br>
sources are completely different, and that means you have different<br>
implementations of the same plugin. In that case, in order to avoid<br>
mess in source tree, it'd be better to separate such implementations<br>
on VCS level.<br>
<br>
But I'd like to hear more opinion from plugin developers.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Igor<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Thu, Feb 11, 2016 at 9:16 AM, Bulat Gaifullin<br>
<<a href="mailto:bgaifullin@mirantis.com">bgaifullin@mirantis.com</a>> wrote:<br>
> I agree with Stas, one rpm - one version.<br>
><br>
> But plugin builder allows to specify several releases as compatible. The<br>
> deployment tasks and repositories can be specified per release, at the same<br>
> time the deployment graph is one for all releases.<br>
> Currently it looks like half-implemented feature. Can we drop this feature?<br>
> or should we finish implementation of this feature.<br>
><br>
><br>
> Regards,<br>
> Bulat Gaifullin<br>
> Mirantis Inc.<br>
><br>
><br>
><br>
> On 11 Feb 2016, at 02:41, Andrew Woodward <<a href="mailto:xarses@gmail.com">xarses@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko <<a href="mailto:dborodaenko@mirantis.com">dborodaenko@mirantis.com</a>><br>
> wrote:<br>
>><br>
>> +1 to Stas, supplanting VCS branches with code duplication is a path to<br>
>> madness and despair. The dubious benefits of a cross-release backwards<br>
>> compatible plugin binary are not worth the code and infra technical debt<br>
>> that such approach would accrue over time.<br>
><br>
><br>
> Supporting multiple fuel releases will likely result in madness as<br>
> discussed, however as we look to support multiple OpenStack releases from<br>
> the same version of fuel, this methodology becomes much more important.<br>
><br>
>><br>
>> On Wed, Feb 10, 2016 at 07:36:30PM +0300, Stanislaw Bogatkin wrote:<br>
>> > It changes mostly nothing for case of furious plugin development when<br>
>> > big<br>
>> > parts of code changed from one release to another.<br>
>> ><br>
>> > You will have 6 different deployment_tasks directories and 30 a little<br>
>> > bit<br>
>> > different files in root directory of plugin. Also you forgot about<br>
>> > repositories directory (+6 at least), pre_build hooks (also 6) and so<br>
>> > on.<br>
>> > It will look as hell after just 3 years of development.<br>
>> ><br>
>> > Also I can't imagine how to deal with plugin licensing if you have<br>
>> > Apache<br>
>> > for liberty but BSD for mitaka release, for example.<br>
>> ><br>
>> > Much easier way to develop a plugin is to keep it's source in VCS like<br>
>> > Git<br>
>> > and just make a branches for every fuel release. It will give us<br>
>> > opportunity to not store a bunch of similar but a little bit different<br>
>> > files in repo. There is no reason to drag all different versions of code<br>
>> > for specific release.<br>
>> ><br>
>> ><br>
>> > On other hand there is a pros - your plugin can survive after upgrade if<br>
>> > it<br>
>> > supports new release, no changes needed here.<br>
>> ><br>
>> > On Wed, Feb 10, 2016 at 4:04 PM, Alexey Shtokolov<br>
>> > <<a href="mailto:ashtokolov@mirantis.com">ashtokolov@mirantis.com</a>><br>
>> > wrote:<br>
>> ><br>
>> > > Fuelers,<br>
>> > ><br>
>> > > We are discussing the idea to extend the multi release packages for<br>
>> > > plugins.<br>
>> > ><br>
>> > > Fuel plugin builder (FPB) can create one rpm-package for all supported<br>
>> > > releases (from metadata.yaml) but we can specify only deployment<br>
>> > > scripts<br>
>> > > and repositories per release.<br>
>> > ><br>
>> > > Current release definition (in metadata.yaml):<br>
>> > > - os: ubuntu<br>
>> > > version: liberty-8.0<br>
>> > > mode: ['ha']<br>
>> > > deployment_scripts_path: deployment_scripts/<br>
>> > > repository_path: repositories/ubuntu<br>
>> > ><br>
><br>
><br>
> This will result in far too much clutter.<br>
> For starters we should support nested over rides. for example the author may<br>
> have already taken account for the changes between one openstack version to<br>
> another. In this case they only should need to define the releases they<br>
> support and not specify any additional locations. Later they may determine<br>
> that they only need to replace packages, or one other file they should not<br>
> be required to code every location for each release<br>
><br>
> Also, at the same time we MUST clean up importing various yaml files.<br>
> Specifically, tasks, volumes, node roles, and network roles. Requiring that<br>
> they all be maintained in a single file doesn't scale, we don't require it<br>
> for tasks.yaml in fuel library, and we should not require it in plugins. We<br>
> should simply do the same thing as tasks.yaml in library, scan the subtree<br>
> for specific file names and just merge them all together. (This has been<br>
> expressed multiple times by people with larger plugins)<br>
><br>
>> > > So the idea [0] is to make releases fully configurable.<br>
>> > > Suggested changes for release definition (in metadata.yaml):<br>
>> > > components_path: components_liberty.yaml<br>
>> > > deployment_tasks_path: deployment_tasks_liberty/ # <- folder<br>
>><br>
>> > > environment_config_path: environment_config_liberty.yaml<br>
>> > > network_roles_path: network_roles_liberty.yaml<br>
>> > > node_roles_path: node_roles_liberty.yaml<br>
>> > > volumes_path: volumes_liberty.yaml<br>
>> > ><br>
>> > > I see the issue: if we change anything for one release (e.g.<br>
>> > > deployment_task typo) revalidation is needed for all releases.<br>
>> > ><br>
>> > > Your Pros and cons please?<br>
>> > ><br>
>> > > [0] <a href="https://review.openstack.org/#/c/271417/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/271417/</a><br>
>> > > ---<br>
>> > > WBR, Alexey Shtokolov<br>
>> > ><br>
>> > ><br>
>> > > __________________________________________________________________________<br>
>> > > OpenStack Development Mailing List (not for usage questions)<br>
>> > > Unsubscribe:<br>
>> > > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>> > ><br>
>> > ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > with best regards,<br>
>> > Stan.<br>
>><br>
>> ><br>
>> > __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe:<br>
>> > <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> --<br>
><br>
> --<br>
><br>
> Andrew Woodward<br>
><br>
> Mirantis<br>
><br>
> Fuel Community Ambassador<br>
><br>
> Ceph Community<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div></div>