<div dir="ltr"><div>What about maintaining a dummy plugin (eg running only one or two very simple tasks) as a standalone project for the purpose of QA?<br>IMO it would make more sense than having those example plugins in the fuel-plugins project...<br></div><div>Regards,<br></div>Simon<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 7, 2016 at 2:49 PM, 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"><span class="">> and really lowering barriers for people who just begin create plugins.<br>
<br>
</span>Nonsense. First, people usually create them via running `fpb --create<br>
plugin-name` that generates plugin boilerplate. And that boilerplate<br>
won't contain that changes.<br>
<br>
Second, if people ain't smart enough to change few lines in<br>
`metadata.yaml` of generated boilerplate to make it work with latest<br>
Fuel, maybe it's better for them to do not develop plugins at all?<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin<br>
<<a href="mailto:sbogatkin@mirantis.com">sbogatkin@mirantis.com</a>> wrote:<br>
> +1 to maintain example plugins. It is easy enough and really lowering<br>
> barriers for people who just begin create plugins.<br>
><br>
> On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn <<a href="mailto:mmosesohn@mirantis.com">mmosesohn@mirantis.com</a>><br>
> wrote:<br>
>><br>
>> 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>
>><br>
>> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky <<a href="mailto:ikalnitsky@mirantis.com">ikalnitsky@mirantis.com</a>><br>
>> 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>><br>
>> > wrote:<br>
>> >> IMHO it is important to keep plugin examples and keep testing them,<br>
>> >> very<br>
>> >> valuable for plugin developers.<br>
>> >><br>
>> >> For example, I've encountered [0] the case where "plugin as role"<br>
>> >> 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<br>
>> >> can/must<br>
>> >> be avoided by testing them.<br>
>> >><br>
>> >> I don't even understand why the question is raised while fuel plugins<br>
>> >> are<br>
>> >> supposed to be supported and more and more used [3], even by murano [4]<br>
>> >> ...<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>
>> >><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<br>
>> >> <<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>
>> >>> __________________________________________________________________________<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>
>> >> 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>
>> > 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>
>> 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>
> with best regards,<br>
> Stan.<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>