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