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

[Mike Scherbakov]

Regarding #2
> we already generate from templates required information for a plugin
developer to start development
and it is great.
So, back to what I said:
> 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).
We already have great template plugins generated by fpb. Question is, how
do we ensure that this generated template actually works.

> # 3 adding real deployment test for fuel-plugins will not help here,
since change in openstack.yaml caused this problem.
True. That's why I started new thread, where I suggest that we must allow
to install older plugins into new releases of Fuel, with the warning only.

> Well, what about tomorrow? On SCF we create stable branches and master is
open for next release. You probably will want to run those tests
against Fuel 10, and FPB's master won't have that "10" release in
examples metadata.
True Igor, please see my same answer to Evgeny above - we need to change
pluggable framework to allow installation of older plugins to newer
releases of Fuel. Before we do that, I suggest to extend supported releases
list right away to Newton. No need to wait for new bug from QA.

On Thu, Mar 10, 2016 at 5:44 AM Igor Kalnitsky 
wrote:

> Well, what about tomorrow? On SCF we create stable branches and master
> is open for next release. You probably will want to run those tests
> against Fuel 10, and FPB's master won't have that "10" release in
> examples metadata. Because it's something that we usually don't want
> to release, and FPB lifecycle is untied from Fuel's.
>
> The only way to avoid that problem is to teach tests to prepare
> plugins themselves. They are like test fixtures, it's not very good
> that your rely on something that you don't maintain.
>
> On Thu, Mar 10, 2016 at 11:01 AM, Evgeniy L  wrote:
> > Mike,
> >
> > # 2 don't agree, we already generate from templates required information
> for
> > a plugin developer to start development, purpose of plugin examples is
> > different, it's used as integration tests for plugins, also QA team uses
> > them as Functional tests, they overloaded with tasks and designed to have
> > good coverage, so it will only confuse plugin developer.
> > # 3 adding real deployment test for fuel-plugins will not help here,
> since
> > change in openstack.yaml caused this problem.
> >
> > Thanks,
> >
> > On Thu, Mar 10, 2016 at 10:55 AM, Matthew Mosesohn <
> mmoses...@mirantis.com>
> > wrote:
> >>
> >> 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
> >>  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  wrote:
> >> >>
> >> >> Because it doesn't make much sense for 

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

[Igor Kalnitsky]

Well, what about tomorrow? On SCF we create stable branches and master
is open for next release. You probably will want to run those tests
against Fuel 10, and FPB's master won't have that "10" release in
examples metadata. Because it's something that we usually don't want
to release, and FPB lifecycle is untied from Fuel's.

The only way to avoid that problem is to teach tests to prepare
plugins themselves. They are like test fixtures, it's not very good
that your rely on something that you don't maintain.

On Thu, Mar 10, 2016 at 11:01 AM, Evgeniy L  wrote:
> Mike,
>
> # 2 don't agree, we already generate from templates required information for
> a plugin developer to start development, purpose of plugin examples is
> different, it's used as integration tests for plugins, also QA team uses
> them as Functional tests, they overloaded with tasks and designed to have
> good coverage, so it will only confuse plugin developer.
> # 3 adding real deployment test for fuel-plugins will not help here, since
> change in openstack.yaml caused this problem.
>
> Thanks,
>
> On Thu, Mar 10, 2016 at 10:55 AM, Matthew Mosesohn 
> wrote:
>>
>> 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
>>  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  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 
>> >> 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  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 
>>  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

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

[Evgeniy L]

Mike,

# 2 don't agree, we already generate from templates required information
for a plugin developer to start development, purpose of plugin examples is
different, it's used as integration tests for plugins, also QA team uses
them as Functional tests, they overloaded with tasks and designed to have
good coverage, so it will only confuse plugin developer.
# 3 adding real deployment test for fuel-plugins will not help here, since
change in openstack.yaml caused this problem.

Thanks,

On Thu, Mar 10, 2016 at 10:55 AM, Matthew Mosesohn 
wrote:

> 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
>  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  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 
> >> 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  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 
>  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
> >  wrote:
> >>
> >> > and really lowering barriers for people who just begin create
> >> > plugins.
> >>
> >> Nonsense. 

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

[Matthew Mosesohn]

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
 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  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 
>> 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  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 
 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
>  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
>>  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
>> > 
>> > wrote:
>> >>
>> >> Igor,
>> >>

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

[Mike Scherbakov]

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  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 
> 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  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 
>>> 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  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
>  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, 

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

[Evgeniy L]

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  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  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 
>> 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 
>>> 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
  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 

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

[Ilya Kutukov]

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  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 
> 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 
>> 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
>>>  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/
>>> >> >>
>>> >> 

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

[Ilya Kutukov]

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  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 
> 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
>>  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 > >
>> >> > 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
>> >> >> 
>> >> >> 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 

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

[Evgeniy L]

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  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 
> 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
>>  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 > >
>> >> > 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
>> >> >> 
>> >> >> 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.
>> >> 

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

[Ilya Kutukov]

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 
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
>  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  >
> > 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  >
> >> 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 
> >> > 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
> >> >> 
> >> >> 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]. 

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

[Evgeniy L]

Hi,

Plugin examples mustn't be removed, those plugins are part of integration
tests for fuel plugin builder, which should be able to build any version of
plugin.

So there are two ways to solve the problem:
1. Before test run update compatibility matrix for plugins automatically.
2. Continue fixing plugin examples.

We may try to do 2nd automatically (proposing a patch with fixed version)
on version change in openstack.yaml.

Thanks,

On Tue, Mar 8, 2016 at 3:50 PM, Anastasia Urlapova 
wrote:

> Igor,
> I agree with folks, that we have to fix plugin. You didn't mention any
> real reasons, why we should change workflow with example-plugin right now
> in the middle of release. If we are keeping support of the example plugin
> in 9.0 it should work from box w/o any black magic in other places.
>
>
> Nastya.
>
> On Mon, Mar 7, 2016 at 6:33 PM, Simon Pasquier 
> wrote:
>
>> Yet another example [1] of why a dummy/example plugin should be
>> integrated in the Fuel CI process: the current version of Fuel is broken
>> for (almost) all plugins since a week at least and no one noticed.
>> Regards,
>> Simon
>>
>> [1] https://bugs.launchpad.net/fuel/+bug/1554095
>>
>> On Mon, Mar 7, 2016 at 3:16 PM, Simon Pasquier 
>> wrote:
>>
>>> 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 
>>> 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
  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]

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

[Simon Pasquier]

Yet another example [1] of why a dummy/example plugin should be integrated
in the Fuel CI process: the current version of Fuel is broken for (almost)
all plugins since a week at least and no one noticed.
Regards,
Simon

[1] https://bugs.launchpad.net/fuel/+bug/1554095

On Mon, Mar 7, 2016 at 3:16 PM, Simon Pasquier 
wrote:

> 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 
> 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
>>  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 > >
>> >> > 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
>> >> >> 
>> >> >> 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 

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

[Simon Pasquier]

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 
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
>  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  >
> > 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  >
> >> 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 
> >> > 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
> >> >> 
> >> >> 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 

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

[Igor Kalnitsky]

> 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
 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 
> 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 
>> 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 
>> > 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
>> >> 
>> >> 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
>> >>>
>> >>>
>> >>> 

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

[Stanislaw Bogatkin]

+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 
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 
> 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 
> 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
> >>
> >
> >
> 

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

[Matthew Mosesohn]

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  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  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 
>> 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: 

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

[Igor Kalnitsky]

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  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 
> 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

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

[Swann Croiset]

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 
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

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

[Alex Schultz]

On Thu, Mar 3, 2016 at 7:19 AM, Matthew Mosesohn  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.
>

IMHO we need to fix the plugins and this should just be part of the
basic maintenance of the plugins for each release cycle. These are
effectively documentation that needs to be updated on a regular basis
and should not be let to go stale.  Integrating with fuel and plugins
is already a complex task so having something that can be used as an
example is very important from an end user experiance standpoint.

>
> 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