<div dir="ltr">Ilya,<div><br></div><div>>> 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.</div><div><br></div><div>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.</div><div><br></div><div>>> <span style="font-size:12.8px">Anyway we need to provide ability to override paths in manifest (metadata.yaml).</span></div><div><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"></div><div><span style="font-size:12.8px">Could you please provide more information on that? I'm not sure if I understand your solution.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Thanks,</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 11, 2016 at 9:35 PM, Ilya Kutukov <span dir="ltr"><<a href="mailto:ikutukov@mirantis.com" target="_blank">ikutukov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br></div><div><br></div>Anyway we need to provide ability to override paths in manifest (metadata.yaml).<div><div><br></div><div>So the plugin developers could use this approaches to provide multiple versions support:</div><div><br></div><div>* tasks logic (do the plugin developers have access to current release info?)</div><div>* 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.</div><div>* 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.</div></div><div><br></div><div>I think its already better than nothing and more flexible than any standardised approach.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 11, 2016 at 6:31 PM, Simon Pasquier <span dir="ltr"><<a href="mailto:spasquier@mirantis.com" target="_blank">spasquier@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<br><div><div class="gmail_extra"><br><div class="gmail_quote"><span>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></span><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...<span><font color="#888888"><br><br></font></span></div><span><font color="#888888"><div>Simon<br></div></font></span><div><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><font color="#888888"><br>
- Igor<br>
</font></span><div><div><br>
On Thu, Feb 11, 2016 at 9:16 AM, Bulat Gaifullin<br>
<<a href="mailto:bgaifullin@mirantis.com" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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></div></div><br></div></div></div>
<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></blockquote></div><br></div>
</div></div><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></blockquote></div><br></div>