Open Stack

r/is almost a copy-paste/is almost a copy-paste from plugins templates

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160309/8da1d096/attachment.html>