Mike, #1 - If you truly agree with that, you should weigh in here: https://review.openstack.org/#/c/287286/ #2 - Requires a blueprint and new docs, but okay. #3 - Yes! We have very poor CI for fuel plugin builder. All it does is ensure it makes a plugin, not that it can be installed and deployed.
On Thu, Mar 10, 2016 at 10:44 AM, Mike Scherbakov <mscherba...@mirantis.com> wrote: > Folks, > here is what I think: > 1) I suggest to fix what is broken now. So that people who come across > examples would not have to deal with issues. We may debate for other few > days (hopefully not more), and all plugin devs will be suffering during this > time. Also, according to Matt, > >> I should add that this is the only automated daily test that will verify > that our plugin framework actually works. > simply means that we must fix it in order to catch any possible regressions > we may introduce later (if not already). > > 2) I like idea Ilya K. has proposed. To rephrase it (to put extra accent > into it and get feedback), we may not need to have example plugins. However, > we can have fpb generating template plugin, with commented code in there. If > you uncomment, you a get a comprehensive example of a working plugin. > To ensure that uncommented code would actually work, we must have a test for > it (which would uncomment - run - ensure everything deploys). > > 3) Ideally, we need to catch issues at pre-commit stage. So I'd suggest to > think if there is a way to have tests, which would run such examples against > pluggable framework for every change to the framework, so that we can have > -1 right away if something goes wrong. > > I've started separate thread on general thoughts about backward > compatibility and multiple releases support, which actually affects > examples: [1] > http://lists.openstack.org/pipermail/openstack-dev/2016-March/088921.html > > Thanks, > > On Wed, Mar 9, 2016 at 7:59 AM Evgeniy L <e...@mirantis.com> wrote: >> >> Because it doesn't make much sense for a plugin developer to have scripts >> to build packages for installation on slave nodes. For default template it's >> better to have something minimalistic and the rest of the tasks commented, >> otherwise it may create a lot of confusion. >> >> On Wed, Mar 9, 2016 at 6:37 PM, Ilya Kutukov <ikutu...@mirantis.com> >> wrote: >>> >>> 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 >>> >> >> __________________________________________________________________________ >> 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 > > -- > Mike Scherbakov > #mihgen > > __________________________________________________________________________ > 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
