Talking about templates I mean plugins generated by FBP from the `templates` folder using command you mentioned above.
Why not to extend (not replace) template-generated plugins with additional data to provide right coverage? On Wed, Mar 9, 2016 at 6:23 PM, Evgeniy L <e...@mirantis.com> wrote: > Ilya, > > What do you mean by "templates" the plugin which is create by just "fpb > --create plugin-name"? > It doesn't cover enough, package installation and all range of tasks > executions. > > Thanks, > > On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov <ikutu...@mirantis.com> > wrote: > >> Igor, i completely agree, actually plugin examples is almost a copy-paste. >> >> 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? >> >> 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. >> >> Eugeny, why not to run integration tests against plugins generated from >> templates? It's will be even better integration tests. >> >> >> >> On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky <ikalnit...@mirantis.com> >> wrote: >> >>> > and really lowering barriers for people who just begin create plugins. >>> >>> Nonsense. First, people usually create them via running `fpb --create >>> plugin-name` that generates plugin boilerplate. And that boilerplate >>> won't contain that changes. >>> >>> Second, if people ain't smart enough to change few lines in >>> `metadata.yaml` of generated boilerplate to make it work with latest >>> Fuel, maybe it's better for them to do not develop plugins at all? >>> >>> On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin >>> <sbogat...@mirantis.com> wrote: >>> > +1 to maintain example plugins. It is easy enough and really lowering >>> > barriers for people who just begin create plugins. >>> > >>> > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn < >>> mmoses...@mirantis.com> >>> > wrote: >>> >> >>> >> Igor, >>> >> >>> >> It seems you are proposing an IKEA approach to plugins. Take Fuel's >>> >> example plugin, add in the current Fuel release, and then build it. We >>> >> maintained these plugins in the past, but now it should a manual step >>> >> to test it out on the current release. >>> >> >>> >> What would be a more ideal situation that meets the needs of users and >>> >> QA? Right now we have failed tests until we can decide on a solution >>> >> that works for everybody. >>> >> >>> >> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky < >>> ikalnit...@mirantis.com> >>> >> wrote: >>> >> > No, this is a wrong road to go. >>> >> > >>> >> > What if in Fuel 10 we drop v1 plugins support? What should we do? >>> >> > Remove v1 example from source tree? That doesn't seem good to me. >>> >> > >>> >> > Example plugins are only examples. The list of supported releases >>> must >>> >> > be maintained on system test side, and system tests must inject that >>> >> > information into plugin's metadata.yaml and test it. >>> >> > >>> >> > Again, I don't say we shouldn't test plugins. I say, tests should be >>> >> > responsible for preparing plugins. I can say even more: tests should >>> >> > not rely on what is produced by plugins, since it's something that >>> >> > could be changed and tests start failing. >>> >> > >>> >> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset < >>> scroi...@mirantis.com> >>> >> > wrote: >>> >> >> IMHO it is important to keep plugin examples and keep testing them, >>> >> >> very >>> >> >> valuable for plugin developers. >>> >> >> >>> >> >> For example, I've encountered [0] the case where "plugin as role" >>> >> >> feature >>> >> >> wasn't easily testable with fuel-qa because not compliant with the >>> last >>> >> >> plugin data structure, >>> >> >> and more recently we've spotted a regression [1] with >>> "vip-reservation" >>> >> >> feature introduced by a change in nailgun. >>> >> >> These kind of issues are time consuming for plugin developers and >>> >> >> can/must >>> >> >> be avoided by testing them. >>> >> >> >>> >> >> I don't even understand why the question is raised while fuel >>> plugins >>> >> >> are >>> >> >> supposed to be supported and more and more used [3], even by >>> murano [4] >>> >> >> ... >>> >> >> >>> >> >> [0] https://bugs.launchpad.net/fuel/+bug/1543962 >>> >> >> [1] https://bugs.launchpad.net/fuel/+bug/1551320 >>> >> >> [3] >>> >> >> >>> >> >> >>> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html >>> >> >> [4] https://review.openstack.org/#/c/286310/ >>> >> >> >>> >> >> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn >>> >> >> <mmoses...@mirantis.com> >>> >> >> wrote: >>> >> >>> >>> >> >>> Hi Fuelers, >>> >> >>> >>> >> >>> I would like to bring your attention a dilemma we have here. It >>> seems >>> >> >>> that there is a dispute as to whether we should maintain the >>> releases >>> >> >>> list for example plugins[0]. In this case, this is for adding >>> version >>> >> >>> 9.0 to the list. >>> >> >>> >>> >> >>> Right now, we run a swarm test that tries to install the example >>> >> >>> plugin and do a deployment, but it's failing only for this >>> reason. I >>> >> >>> should add that this is the only automated daily test that will >>> verify >>> >> >>> that our plugin framework actually works. During the Mitaka >>> >> >>> development cycle, we already had an extended period where >>> plugins >>> >> >>> were broken[1]. Removing this test (or leaving it permanently red, >>> >> >>> which is effectively the same), would raise the risk to any >>> member of >>> >> >>> the Fuel community who depends on plugins actually working. >>> >> >>> >>> >> >>> The other impact of abandoning maintenance of example plugins is >>> that >>> >> >>> it means that a given interested Fuel Plugin developer would not >>> be >>> >> >>> able to easily get started with plugin development. It might not >>> be >>> >> >>> inherently obvious to add the current Fuel release to the >>> >> >>> metadata.yaml file and it would likely discourage such a user. In >>> this >>> >> >>> case, I would propose that we remove example plugins from >>> fuel-plugins >>> >> >>> GIT repo if they are not maintained. Non-functioning code is worse >>> >> >>> than deleted code in my opinion. >>> >> >>> >>> >> >>> Please share your opinions and let's decide which way to go with >>> this >>> >> >>> bug[2] >>> >> >>> >>> >> >>> [0] >>> https://github.com/openstack/fuel-plugins/tree/master/examples >>> >> >>> [1] https://bugs.launchpad.net/fuel/+bug/1544505 >>> >> >>> [2] https://launchpad.net/bugs/1548340 >>> >> >>> >>> >> >>> Best Regards, >>> >> >>> Matthew Mosesohn >>> >> >>> >>> >> >>> >>> >> >>> >>> __________________________________________________________________________ >>> >> >>> OpenStack Development Mailing List (not for usage questions) >>> >> >>> Unsubscribe: >>> >> >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> >> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> __________________________________________________________________________ >>> >> >> OpenStack Development Mailing List (not for usage questions) >>> >> >> Unsubscribe: >>> >> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >>> >> > >>> >> > >>> >> > >>> __________________________________________________________________________ >>> >> > OpenStack Development Mailing List (not for usage questions) >>> >> > Unsubscribe: >>> >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >>> >> >>> __________________________________________________________________________ >>> >> OpenStack Development Mailing List (not for usage questions) >>> >> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> > >>> > >>> > >>> > -- >>> > with best regards, >>> > Stan. >>> > >>> > >>> __________________________________________________________________________ >>> > OpenStack Development Mailing List (not for usage questions) >>> > Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
