<div dir="ltr">+1 to maintain example plugins. It is easy enough and really lowering barriers for people who just begin create plugins.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn <span dir="ltr"><<a href="mailto:mmosesohn@mirantis.com" target="_blank">mmosesohn@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Igor,<br>
<br>
It seems you are proposing an IKEA approach to plugins. Take Fuel's<br>
example plugin, add in the current Fuel release, and then build it. We<br>
maintained these plugins in the past, but now it should a manual step<br>
to test it out on the current release.<br>
<br>
What would be a more ideal situation that meets the needs of users and<br>
QA? Right now we have failed tests until we can decide on a solution<br>
that works for everybody.<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>> wrote:<br>
> No, this is a wrong road to go.<br>
><br>
> What if in Fuel 10 we drop v1 plugins support? What should we do?<br>
> Remove v1 example from source tree? That doesn't seem good to me.<br>
><br>
> Example plugins are only examples. The list of supported releases must<br>
> be maintained on system test side, and system tests must inject that<br>
> information into plugin's metadata.yaml and test it.<br>
><br>
> Again, I don't say we shouldn't test plugins. I say, tests should be<br>
> responsible for preparing plugins. I can say even more: tests should<br>
> not rely on what is produced by plugins, since it's something that<br>
> could be changed and tests start failing.<br>
><br>
> On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset <<a href="mailto:scroiset@mirantis.com">scroiset@mirantis.com</a>> wrote:<br>
>> IMHO it is important to keep plugin examples and keep testing them, very<br>
>> valuable for plugin developers.<br>
>><br>
>> For example, I've encountered [0] the case where "plugin as role" feature<br>
>> wasn't easily testable with fuel-qa because not compliant with the last<br>
>> plugin data structure,<br>
>> and more recently we've spotted a regression [1] with "vip-reservation"<br>
>> feature introduced by a change in nailgun.<br>
>> These kind of issues are time consuming for plugin developers and can/must<br>
>> be avoided by testing them.<br>
>><br>
>> I don't even understand why the question is raised while fuel plugins are<br>
>> supposed to be supported and more and more used [3], even by murano [4] ...<br>
>><br>
>> [0] <a href="https://bugs.launchpad.net/fuel/+bug/1543962" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1543962</a><br>
>> [1] <a href="https://bugs.launchpad.net/fuel/+bug/1551320" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1551320</a><br>
>> [3]<br>
>> <a href="http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html</a><br>
>> [4] <a href="https://review.openstack.org/#/c/286310/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/286310/</a><br>
>><br>
>> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn <<a href="mailto:mmosesohn@mirantis.com">mmosesohn@mirantis.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hi Fuelers,<br>
>>><br>
>>> I would like to bring your attention a dilemma we have here. It seems<br>
>>> that there is a dispute as to whether we should maintain the releases<br>
>>> list for example plugins[0]. In this case, this is for adding version<br>
>>> 9.0 to the list.<br>
>>><br>
>>> Right now, we run a swarm test that tries to install the example<br>
>>> plugin and do a deployment, but it's failing only for this reason. I<br>
>>> should add that this is the only automated daily test that will verify<br>
>>> that our plugin framework actually works. During the Mitaka<br>
>>> developmentĀ  cycle, we already had an extended period where plugins<br>
>>> were broken[1]. Removing this test (or leaving it permanently red,<br>
>>> which is effectively the same), would raise the risk to any member of<br>
>>> the Fuel community who depends on plugins actually working.<br>
>>><br>
>>> The other impact of abandoning maintenance of example plugins is that<br>
>>> it means that a given interested Fuel Plugin developer would not be<br>
>>> able to easily get started with plugin development. It might not be<br>
>>> inherently obvious to add the current Fuel release to the<br>
>>> metadata.yaml file and it would likely discourage such a user. In this<br>
>>> case, I would propose that we remove example plugins from fuel-plugins<br>
>>> GIT repo if they are not maintained. Non-functioning code is worse<br>
>>> than deleted code in my opinion.<br>
>>><br>
>>> Please share your opinions and let's decide which way to go with this<br>
>>> bug[2]<br>
>>><br>
>>> [0] <a href="https://github.com/openstack/fuel-plugins/tree/master/examples" rel="noreferrer" target="_blank">https://github.com/openstack/fuel-plugins/tree/master/examples</a><br>
>>> [1] <a href="https://bugs.launchpad.net/fuel/+bug/1544505" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1544505</a><br>
>>> [2] <a href="https://launchpad.net/bugs/1548340" rel="noreferrer" target="_blank">https://launchpad.net/bugs/1548340</a><br>
>>><br>
>>> Best Regards,<br>
>>> Matthew Mosesohn<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>
<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><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>