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

Matthew Mosesohn mmosesohn at mirantis.com
Thu Mar 10 07:55:12 UTC 2016


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
<mscherbakov at 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 <eli at 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 <ikutukov at 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 <eli at 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 <ikutukov at 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
>>>>> <ikalnitsky at 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
>>>>>> <sbogatkin at 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
>>>>>> > <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.
>>>>>> >
>>>>>> >
>>>>>> > __________________________________________________________________________
>>>>>> > 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
>>>>
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>
> --
> Mike Scherbakov
> #mihgen
>
> __________________________________________________________________________
> 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
>



More information about the OpenStack-dev mailing list