What about maintaining a dummy plugin (eg running only one or two very simple tasks) as a standalone project for the purpose of QA? IMO it would make more sense than having those example plugins in the fuel-plugins project... Regards, Simon
On Mon, Mar 7, 2016 at 2: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
