Open Stack

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