Open Stack

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 <ikalnitsky at mirantis.com>
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 <eli at mirantis.com> 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 <
> mmosesohn at 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
> >> <mscherbakov at mirantis.com> wrote:
> >> > Folks,
> >> > here is what I think:
> >> > 1) I suggest to fix what is broken now. So that people who come across
> >> > examples would not have to deal with issues. We may debate for other
> few
> >> > days (hopefully not more), and all plugin devs will be suffering
> during
> >> > this
> >> > time. Also, according to Matt,
> >> >
> >> >> I should add that this is the only automated daily test that will
> >> >> verify
> >> > that our plugin framework actually works.
> >> > simply means that we must fix it in order to catch any possible
> >> > regressions
> >> > we may introduce later (if not already).
> >> >
> >> > 2) I like idea Ilya K. has proposed. To rephrase it (to put extra
> accent
> >> > into it and get feedback), we may not need to have example plugins.
> >> > However,
> >> > we can have fpb generating template plugin, with commented code in
> >> > there. If
> >> > you uncomment, you a get a comprehensive example of a working plugin.
> >> > To ensure that uncommented code would actually work, we must have a
> test
> >> > for
> >> > it (which would uncomment - run - ensure everything deploys).
> >> >
> >> > 3) Ideally, we need to catch issues at pre-commit stage. So I'd
> suggest
> >> > to
> >> > think if there is a way to have tests, which would run such examples
> >> > against
> >> > pluggable framework for every change to the framework, so that we can
> >> > have
> >> > -1 right away if something goes wrong.
> >> >
> >> > I've started separate thread on general thoughts about backward
> >> > compatibility and multiple releases support, which actually affects
> >> > examples: [1]
> >> >
> >> >
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088921.html
> >> >
> >> > Thanks,
> >> >
> >> > On Wed, Mar 9, 2016 at 7:59 AM Evgeniy L <eli at mirantis.com> wrote:
> >> >>
> >> >> Because it doesn't make much sense for a plugin developer to have
> >> >> scripts
> >> >> to build packages for installation on slave nodes. For default
> template
> >> >> it's
> >> >> better to have something minimalistic and the rest of the tasks
> >> >> commented,
> >> >> otherwise it may create a lot of confusion.
> >> >>
> >> >> On Wed, Mar 9, 2016 at 6:37 PM, Ilya Kutukov <ikutukov at mirantis.com>
> >> >> wrote:
> >> >>>
> >> >>> Talking about templates I mean plugins generated by FBP from the
> >> >>> `templates` folder using command you mentioned above.
> >> >>>
> >> >>> Why not to extend (not replace) template-generated plugins with
> >> >>> additional data to provide right coverage?
> >> >>>
> >> >>> On Wed, Mar 9, 2016 at 6:23 PM, Evgeniy L <eli at mirantis.com> wrote:
> >> >>>>
> >> >>>> Ilya,
> >> >>>>
> >> >>>> What do you mean by "templates" the plugin which is create by just
> >> >>>> "fpb
> >> >>>> --create plugin-name"?
> >> >>>> It doesn't cover enough, package installation and all range of
> tasks
> >> >>>> executions.
> >> >>>>
> >> >>>> Thanks,
> >> >>>>
> >> >>>> On Wed, Mar 9, 2016 at 6:16 PM, Ilya Kutukov <
> ikutukov at mirantis.com>
> >> >>>> wrote:
> >> >>>>>
> >> >>>>> Igor, i completely agree, actually plugin examples is almost a
> >> >>>>> copy-paste.
> >> >>>>>
> >> >>>>> The only thing i see useful in the built plugins example is the
> >> >>>>> ability
> >> >>>>> to point some code lines, discussing plugin design and writing
> >> >>>>> documentation. Why not to generate this examples automatically
> from
> >> >>>>> templates?
> >> >>>>>
> >> >>>>> Also, as developer and administrator i love to use
> >> >>>>> examples/templates
> >> >>>>> where all essential settings and options are persist but commented
> >> >>>>> (e.g.
> >> >>>>> ProFTPD or Apache) and i could uncomment and copy-paste them not
> >> >>>>> being
> >> >>>>> afraid of typos. Also it allows to keep documentation actual and
> >> >>>>> head
> >> >>>>> documentation small. Duplication of inline documentation between
> >> >>>>> examples
> >> >>>>> and templates making things more weird and overshadows idea of
> >> >>>>> inline
> >> >>>>> documentation itself.
> >> >>>>>
> >> >>>>> Eugeny, why not to run integration tests against plugins generated
> >> >>>>> from
> >> >>>>> templates? It's will be even better integration tests.
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> On Mon, Mar 7, 2016 at 4:49 PM, Igor Kalnitsky
> >> >>>>> <ikalnitsky at mirantis.com> wrote:
> >> >>>>>>
> >> >>>>>> > and really lowering barriers for people who just begin create
> >> >>>>>> > plugins.
> >> >>>>>>
> >> >>>>>> Nonsense. First, people usually create them via running `fpb
> >> >>>>>> --create
> >> >>>>>> plugin-name` that generates plugin boilerplate. And that
> >> >>>>>> boilerplate
> >> >>>>>> won't contain that changes.
> >> >>>>>>
> >> >>>>>> Second, if people ain't smart enough to change few lines in
> >> >>>>>> `metadata.yaml` of generated boilerplate to make it work with
> >> >>>>>> latest
> >> >>>>>> Fuel, maybe it's better for them to do not develop plugins at
> all?
> >> >>>>>>
> >> >>>>>> On Fri, Mar 4, 2016 at 2:24 PM, Stanislaw Bogatkin
> >> >>>>>> <sbogatkin at mirantis.com> wrote:
> >> >>>>>> > +1 to maintain example plugins. It is easy enough and really
> >> >>>>>> > lowering
> >> >>>>>> > barriers for people who just begin create plugins.
> >> >>>>>> >
> >> >>>>>> > On Fri, Mar 4, 2016 at 2:08 PM, Matthew Mosesohn
> >> >>>>>> > <mmosesohn at mirantis.com>
> >> >>>>>> > wrote:
> >> >>>>>> >>
> >> >>>>>> >> Igor,
> >> >>>>>> >>
> >> >>>>>> >> It seems you are proposing an IKEA approach to plugins. Take
> >> >>>>>> >> Fuel's
> >> >>>>>> >> example plugin, add in the current Fuel release, and then
> build
> >> >>>>>> >> it.
> >> >>>>>> >> We
> >> >>>>>> >> maintained these plugins in the past, but now it should a
> manual
> >> >>>>>> >> step
> >> >>>>>> >> to test it out on the current release.
> >> >>>>>> >>
> >> >>>>>> >> What would be a more ideal situation that meets the needs of
> >> >>>>>> >> users
> >> >>>>>> >> and
> >> >>>>>> >> QA? Right now we have failed tests until we can decide on a
> >> >>>>>> >> solution
> >> >>>>>> >> that works for everybody.
> >> >>>>>> >>
> >> >>>>>> >> On Fri, Mar 4, 2016 at 1:26 PM, Igor Kalnitsky
> >> >>>>>> >> <ikalnitsky at mirantis.com>
> >> >>>>>> >> wrote:
> >> >>>>>> >> > No, this is a wrong road to go.
> >> >>>>>> >> >
> >> >>>>>> >> > What if in Fuel 10 we drop v1 plugins support? What should
> we
> >> >>>>>> >> > do?
> >> >>>>>> >> > Remove v1 example from source tree? That doesn't seem good
> to
> >> >>>>>> >> > me.
> >> >>>>>> >> >
> >> >>>>>> >> > Example plugins are only examples. The list of supported
> >> >>>>>> >> > releases
> >> >>>>>> >> > must
> >> >>>>>> >> > be maintained on system test side, and system tests must
> >> >>>>>> >> > inject
> >> >>>>>> >> > that
> >> >>>>>> >> > information into plugin's metadata.yaml and test it.
> >> >>>>>> >> >
> >> >>>>>> >> > Again, I don't say we shouldn't test plugins. I say, tests
> >> >>>>>> >> > should
> >> >>>>>> >> > be
> >> >>>>>> >> > responsible for preparing plugins. I can say even more:
> tests
> >> >>>>>> >> > should
> >> >>>>>> >> > not rely on what is produced by plugins, since it's
> something
> >> >>>>>> >> > that
> >> >>>>>> >> > could be changed and tests start failing.
> >> >>>>>> >> >
> >> >>>>>> >> > On Thu, Mar 3, 2016 at 7:54 PM, Swann Croiset
> >> >>>>>> >> > <scroiset at mirantis.com>
> >> >>>>>> >> > wrote:
> >> >>>>>> >> >> IMHO it is important to keep plugin examples and keep
> testing
> >> >>>>>> >> >> them,
> >> >>>>>> >> >> very
> >> >>>>>> >> >> valuable for plugin developers.
> >> >>>>>> >> >>
> >> >>>>>> >> >> For example, I've encountered [0] the case where "plugin as
> >> >>>>>> >> >> role"
> >> >>>>>> >> >> feature
> >> >>>>>> >> >> wasn't easily testable with fuel-qa because not compliant
> >> >>>>>> >> >> with
> >> >>>>>> >> >> the last
> >> >>>>>> >> >> plugin data structure,
> >> >>>>>> >> >> and more recently we've spotted a regression [1] with
> >> >>>>>> >> >> "vip-reservation"
> >> >>>>>> >> >> feature introduced by a change in nailgun.
> >> >>>>>> >> >> These kind of issues are time consuming for plugin
> developers
> >> >>>>>> >> >> and
> >> >>>>>> >> >> can/must
> >> >>>>>> >> >> be avoided by testing them.
> >> >>>>>> >> >>
> >> >>>>>> >> >> I don't even understand why the question is raised while
> fuel
> >> >>>>>> >> >> plugins
> >> >>>>>> >> >> are
> >> >>>>>> >> >> supposed to be supported and more and more used [3], even
> by
> >> >>>>>> >> >> murano [4]
> >> >>>>>> >> >> ...
> >> >>>>>> >> >>
> >> >>>>>> >> >> [0] https://bugs.launchpad.net/fuel/+bug/1543962
> >> >>>>>> >> >> [1] https://bugs.launchpad.net/fuel/+bug/1551320
> >> >>>>>> >> >> [3]
> >> >>>>>> >> >>
> >> >>>>>> >> >>
> >> >>>>>> >> >>
> >> >>>>>> >> >>
> http://lists.openstack.org/pipermail/openstack-dev/2016-February/085636.html
> >> >>>>>> >> >> [4] https://review.openstack.org/#/c/286310/
> >> >>>>>> >> >>
> >> >>>>>> >> >> On Thu, Mar 3, 2016 at 3:19 PM, Matthew Mosesohn
> >> >>>>>> >> >> <mmosesohn at mirantis.com>
> >> >>>>>> >> >> wrote:
> >> >>>>>> >> >>>
> >> >>>>>> >> >>> Hi Fuelers,
> >> >>>>>> >> >>>
> >> >>>>>> >> >>> I would like to bring your attention a dilemma we have
> here.
> >> >>>>>> >> >>> It
> >> >>>>>> >> >>> seems
> >> >>>>>> >> >>> that there is a dispute as to whether we should maintain
> the
> >> >>>>>> >> >>> releases
> >> >>>>>> >> >>> list for example plugins[0]. In this case, this is for
> >> >>>>>> >> >>> adding
> >> >>>>>> >> >>> version
> >> >>>>>> >> >>> 9.0 to the list.
> >> >>>>>> >> >>>
> >> >>>>>> >> >>> Right now, we run a swarm test that tries to install the
> >> >>>>>> >> >>> example
> >> >>>>>> >> >>> plugin and do a deployment, but it's failing only for this
> >> >>>>>> >> >>> reason. I
> >> >>>>>> >> >>> should add that this is the only automated daily test that
> >> >>>>>> >> >>> will
> >> >>>>>> >> >>> verify
> >> >>>>>> >> >>> that our plugin framework actually works. During the
> Mitaka
> >> >>>>>> >> >>> development  cycle, we already had an extended period
> where
> >> >>>>>> >> >>> plugins
> >> >>>>>> >> >>> were broken[1]. Removing this test (or leaving it
> >> >>>>>> >> >>> permanently
> >> >>>>>> >> >>> red,
> >> >>>>>> >> >>> which is effectively the same), would raise the risk to
> any
> >> >>>>>> >> >>> member of
> >> >>>>>> >> >>> the Fuel community who depends on plugins actually
> working.
> >> >>>>>> >> >>>
> >> >>>>>> >> >>> The other impact of abandoning maintenance of example
> >> >>>>>> >> >>> plugins
> >> >>>>>> >> >>> is that
> >> >>>>>> >> >>> it means that a given interested Fuel Plugin developer
> would
> >> >>>>>> >> >>> not be
> >> >>>>>> >> >>> able to easily get started with plugin development. It
> might
> >> >>>>>> >> >>> not be
> >> >>>>>> >> >>> inherently obvious to add the current Fuel release to the
> >> >>>>>> >> >>> metadata.yaml file and it would likely discourage such a
> >> >>>>>> >> >>> user.
> >> >>>>>> >> >>> In this
> >> >>>>>> >> >>> case, I would propose that we remove example plugins from
> >> >>>>>> >> >>> fuel-plugins
> >> >>>>>> >> >>> GIT repo if they are not maintained. Non-functioning code
> is
> >> >>>>>> >> >>> worse
> >> >>>>>> >> >>> than deleted code in my opinion.
> >> >>>>>> >> >>>
> >> >>>>>> >> >>> Please share your opinions and let's decide which way to
> go
> >> >>>>>> >> >>> with this
> >> >>>>>> >> >>> bug[2]
> >> >>>>>> >> >>>
> >> >>>>>> >> >>> [0]
> >> >>>>>> >> >>>
> >> >>>>>> >> >>>
> https://github.com/openstack/fuel-plugins/tree/master/examples
> >> >>>>>> >> >>> [1] https://bugs.launchpad.net/fuel/+bug/1544505
> >> >>>>>> >> >>> [2] https://launchpad.net/bugs/1548340
> >> >>>>>> >> >>>
> >> >>>>>> >> >>> Best Regards,
> >> >>>>>> >> >>> Matthew Mosesohn
> >> >>>>>> >> >>>
> >> >>>>>> >> >>>
> >> >>>>>> >> >>>
> >> >>>>>> >> >>>
> >> >>>>>> >> >>>
> __________________________________________________________________________
> >> >>>>>> >> >>> OpenStack Development Mailing List (not for usage
> questions)
> >> >>>>>> >> >>> Unsubscribe:
> >> >>>>>> >> >>>
> >> >>>>>> >> >>>
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> >>>>>> >> >>>
> >> >>>>>> >> >>>
> >> >>>>>> >> >>>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >>>>>> >> >>
> >> >>>>>> >> >>
> >> >>>>>> >> >>
> >> >>>>>> >> >>
> >> >>>>>> >> >>
> >> >>>>>> >> >>
> >> >>>>>> >> >>
> __________________________________________________________________________
> >> >>>>>> >> >> OpenStack Development Mailing List (not for usage
> questions)
> >> >>>>>> >> >> Unsubscribe:
> >> >>>>>> >> >>
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> >>>>>> >> >>
> >> >>>>>> >> >>
> >> >>>>>> >> >>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >>>>>> >> >>
> >> >>>>>> >> >
> >> >>>>>> >> >
> >> >>>>>> >> >
> >> >>>>>> >> >
> >> >>>>>> >> >
> __________________________________________________________________________
> >> >>>>>> >> > OpenStack Development Mailing List (not for usage questions)
> >> >>>>>> >> > Unsubscribe:
> >> >>>>>> >> >
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> >>>>>> >> >
> >> >>>>>> >> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >>>>>> >>
> >> >>>>>> >>
> >> >>>>>> >>
> >> >>>>>> >>
> __________________________________________________________________________
> >> >>>>>> >> OpenStack Development Mailing List (not for usage questions)
> >> >>>>>> >> Unsubscribe:
> >> >>>>>> >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> >>>>>> >>
> >> >>>>>> >>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >>>>>> >
> >> >>>>>> >
> >> >>>>>> >
> >> >>>>>> >
> >> >>>>>> > --
> >> >>>>>> > with best regards,
> >> >>>>>> > Stan.
> >> >>>>>> >
> >> >>>>>> >
> >> >>>>>> >
> >> >>>>>> >
> __________________________________________________________________________
> >> >>>>>> > OpenStack Development Mailing List (not for usage questions)
> >> >>>>>> > Unsubscribe:
> >> >>>>>> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> >>>>>> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >>>>>> >
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> __________________________________________________________________________
> >> >>>>>> OpenStack Development Mailing List (not for usage questions)
> >> >>>>>> Unsubscribe:
> >> >>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> >>>>>>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> __________________________________________________________________________
> >> >>>>> OpenStack Development Mailing List (not for usage questions)
> >> >>>>> Unsubscribe:
> >> >>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> __________________________________________________________________________
> >> >>>> OpenStack Development Mailing List (not for usage questions)
> >> >>>> Unsubscribe:
> >> >>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >>>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> __________________________________________________________________________
> >> >>> OpenStack Development Mailing List (not for usage questions)
> >> >>> Unsubscribe:
> >> >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >>>
> >> >>
> >> >>
> >> >>
> __________________________________________________________________________
> >> >> OpenStack Development Mailing List (not for usage questions)
> >> >> Unsubscribe:
> >> >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >> > --
> >> > Mike Scherbakov
> >> > #mihgen
> >> >
> >> >
> >> >
> __________________________________________________________________________
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> >> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160311/8e9d8429/attachment.html>