<div dir="ltr">Sorry for the typo "s/<span style="font-size:12.8px">I can shade more light/</span><span style="font-size:12.8px">I can shed more light/"</span></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 11, 2016 at 1:51 PM, Evgeniy L <span dir="ltr"><<a href="mailto:eli@mirantis.com" target="_blank">eli@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,<div><br></div><div>As an author of this part of pluggable architecture I can shade more light</div><div>on why it was implemented this way and why it's valuable to continue</div><div>supporting multi-release feature.</div><div><br></div><div>At the time it was implemented Fuel officially was supporting both Ubuntu</div><div>and CentOS, in order to simplify plugins distribution development and support,</div><div>plugin developer was able to create a single plugin which supports both</div><div>operating systems, deployment scripts in the most cases support both</div><div>operating systems, if they are not, there is enough flexibility to specify</div><div>different set of deployment scripts and repositories.</div><div><br></div><div>We don't force plugin developer to support all range of releases in a single</div><div>plugin, it's up to plugin developer to decide what mechanism is better for</div><div>specific plugin, I'm strongly against of making "single release a.k.a os" plugins.</div><div><br></div><div>Also suggested change will dramatically complicate distribution when we</div><div>get heterogeneous environments (different operating system in a single</div><div>environment).</div><div><br></div><div>Bulat is right that there are issues, but those issues has to be fixed, and</div><div>there is straightforward way to do it.</div><div><br></div><div>To summarise, I don't think that we should force the developer to follow</div><div>specific release schema, let the developer decide.</div><div><br></div><div>Thanks,</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 11, 2016 at 10:16 AM, Bulat Gaifullin <span dir="ltr"><<a href="mailto:bgaifullin@mirantis.com" target="_blank">bgaifullin@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 style="word-wrap:break-word">I agree with Stas, one rpm - one version.<div><br></div><div>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.</div><div>Currently it looks like half-implemented feature. Can we drop this feature? or should we finish implementation of this feature.</div><div><br></div><div><div><div><br><div>
Regards,<br>Bulat Gaifullin<br>Mirantis Inc.<div><br></div><br>
</div><div><div>
<br><div><blockquote type="cite"><div>On 11 Feb 2016, at 02:41, Andrew Woodward <<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>> wrote:</div><br><div><div dir="ltr" style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 10, 2016 at 2:23 PM Dmitry Borodaenko <<a href="mailto:dborodaenko@mirantis.com" target="_blank">dborodaenko@mirantis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">+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></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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 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 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 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 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 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 it<br>> supports new release, no changes needed here.<br>><br>> On Wed, Feb 10, 2016 at 4:04 PM, Alexey Shtokolov <<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 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></blockquote><div><br></div><div>This will result in far too much clutter.</div><div>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</div><div><br></div><div>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)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> > 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 </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> > 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]<span> </span><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>> > OpenStack Development Mailing List (not for usage questions)<br>> > Unsubscribe:<span> </span><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>> ><span> </span><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>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe:<span> </span><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>><span> </span><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:<span> </span><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></blockquote></div></div><div dir="ltr" style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">--<span> </span><br></div><div dir="ltr" style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><p dir="ltr">--</p><p dir="ltr"><span style="font-size:13.1999998092651px">Andrew Woodward</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Mirantis</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Fuel Community Ambassador</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Ceph Community</span></p></div><span style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">__________________________________________________________________________</span><br style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">OpenStack Development Mailing List (not for usage questions)</span><br style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Unsubscribe:<span> </span></span><a href="mailto:OpenStack-dev-request@lists.openstack.org" style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">OpenStack-dev-request@lists.openstack.org</a><span style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">?subject:unsubscribe</span><br style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" style="font-family:Helvetica;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></blockquote></div><br></div></div></div></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></blockquote></div><br></div>