<div dir="ltr"><div>It changes mostly nothing for case of furious plugin development when big parts of code changed from one release to another.</div><div><br></div>You will have 6 different <span style="font-size:12.8px">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.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Also I can't imagine how to deal with plugin licensing if you have Apache for liberty but BSD for mitaka release, for example.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">On other hand there is a pros - your plugin can survive after upgrade if it supports new release, no changes needed here.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 10, 2016 at 4:04 PM, Alexey Shtokolov <span dir="ltr"><<a href="mailto:ashtokolov@mirantis.com" target="_blank">ashtokolov@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">Fuelers,<div><br></div><div>We are discussing the idea to extend the multi release packages for plugins.</div><div><br></div><div>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.</div><div><br></div><div>Current release definition (in metadata.yaml):</div><div><div> - os: ubuntu</div><div> version: liberty-8.0</div><div> mode: ['ha']</div><div> deployment_scripts_path: deployment_scripts/</div><div> repository_path: repositories/ubuntu</div></div><div><br></div><div>So the idea [0] is to make releases fully configurable.</div><div><div>Suggested changes for release definition (in metadata.yaml):</div><div> components_path: components_liberty.yaml</div><div> deployment_tasks_path: deployment_tasks_liberty/ # <- folder</div><div> environment_config_path: environment_config_liberty.yaml</div><div> network_roles_path: network_roles_liberty.yaml</div><div> node_roles_path: node_roles_liberty.yaml</div><div> volumes_path: volumes_liberty.yaml</div><div><br></div><div>I see the issue: if we change anything for one release (e.g. deployment_task typo) revalidation is needed for all releases.</div><div> </div><div>Your Pros and cons please?<br></div><div><br></div><div>[0] <a href="https://review.openstack.org/#/c/271417/" target="_blank">https://review.openstack.org/#/c/271417/</a></div><div><div dir="ltr">---<div>WBR, Alexey Shtokolov</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><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>with best regards,</div><div>Stan.</div></div></div></div></div>
</div>