[openstack-dev] [fuel][plugins] Should we maintain example plugins?

Stanislaw Bogatkin sbogatkin at mirantis.com
Fri Mar 4 12:24:52 UTC 2016


+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 <mmosesohn at 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 <ikalnitsky at 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 <scroiset at 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 <
> mmosesohn at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
with best regards,
Stan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160304/acd25968/attachment.html>


More information about the OpenStack-dev mailing list