<div dir="ltr">r/<span style="font-size:12.8px">is almost a copy-paste/</span><span style="font-size:12.8px">is almost a copy-paste from plugins templates</span></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 9, 2016 at 6:16 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">Igor, i completely agree, actually plugin examples is almost a copy-paste.<div><br><div>The only thing i see useful in the built plugins example is the ability to point some code lines, discussing plugin design and writing documentation. Why not to generate this examples automatically from templates?</div><div><div><br></div><div>Also, as developer and administrator i love to use examples/templates where all essential settings and options are persist but commented (e.g. ProFTPD or Apache) and i could uncomment and copy-paste them not being afraid of typos. Also it allows to keep documentation actual and head documentation small. Duplication of inline documentation between examples and templates making things more weird and overshadows idea of inline documentation itself.<br></div><div><br></div><div>Eugeny, why not to run integration tests against plugins generated from templates? It's will be even better integration tests.<br></div><div><br></div><div><br></div></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 7, 2016 at 4: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>> 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><div><br>
On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin<br>
<<a href="mailto:sbogatkin@mirantis.com" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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>
</div></div></blockquote></div><br></div>