settingsLogin | Registersettings

[openstack-dev] [Fuel] Plugins for Fuel: repo, doc, spec - where?

0 votes

Hi Fuelers,
we've implemented pluggable architecture piece in 6.0, and got a number of
plugins already. Overall development process for plugins is still not fully
defined.
We initially thought that having all the plugins in one repo on stackforge
is Ok, we also put some docs into existing fuel-docs repo, and specs to
fuel-specs.

We might need a change here. Plugins are not tight to any particular
release date, and they can also be separated each from other in terms of
committers and core reviewers. Also, it seems to be pretty natural to keep
all docs and design specs associated with particular plugin.

With all said, following best dev practices, it is suggested to:

  1. Have a separate stackforge repo per Fuel plugin in format
    "fuel-plugin-", with separate core-reviewers group which should have
    plugin contributor initially
  2. Have docs folder in the plugin, and ability to build docs out of it

    • do we want Sphinx or simple Github docs format is Ok? So people can
      just go to github/stackforge to see docs
  3. Have specification in the plugin repo

    • also, do we need Sphinx here?
  4. Have plugins tests in the repo

Ideas / suggestions / comments?
Thanks,
--
Mike Scherbakov

mihgen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openstack.org/pipermail/openstack-dev/attachments/20150123/6070ad79/attachment.html

asked Jan 22, 2015 in openstack-dev by Mike_Scherbakov (9,460 points)   1 4 6
retagged Jan 28, 2015 by admin

7 Responses

0 votes

I also wanted to add that there is a PR already on adding plugins
repos to stackforge: https://review.openstack.org/#/c/147169/

There is a battle in comments right now, because some people are not
agree that so many repos are needed.

On Fri, Jan 23, 2015 at 1:25 AM, Mike Scherbakov
wrote:
Hi Fuelers,
we've implemented pluggable architecture piece in 6.0, and got a number of
plugins already. Overall development process for plugins is still not fully
defined.
We initially thought that having all the plugins in one repo on stackforge
is Ok, we also put some docs into existing fuel-docs repo, and specs to
fuel-specs.

We might need a change here. Plugins are not tight to any particular release
date, and they can also be separated each from other in terms of committers
and core reviewers. Also, it seems to be pretty natural to keep all docs and
design specs associated with particular plugin.

With all said, following best dev practices, it is suggested to:

Have a separate stackforge repo per Fuel plugin in format
"fuel-plugin-", with separate core-reviewers group which should have
plugin contributor initially
Have docs folder in the plugin, and ability to build docs out of it

do we want Sphinx or simple Github docs format is Ok? So people can just go
to github/stackforge to see docs

Have specification in the plugin repo

also, do we need Sphinx here?

Have plugins tests in the repo

Ideas / suggestions / comments?
Thanks,
--
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

--
Best regards,
Nick Markov

responded Jan 23, 2015 by Nikolay_Markov (1,260 points)   1 2
0 votes

What sort of specification are you talking about here -- specs for
individual plugins
or a spec for how to implement a plugin? If the latter, what is the
relationship of that
to the official documentation about how to create a plugin (to be added to
the
Developer Guide)?

meg

On Fri, Jan 23, 2015 at 1:43 AM, Nikolay Markov
wrote:

I also wanted to add that there is a PR already on adding plugins
repos to stackforge: https://review.openstack.org/#/c/147169/

There is a battle in comments right now, because some people are not
agree that so many repos are needed.

On Fri, Jan 23, 2015 at 1:25 AM, Mike Scherbakov
wrote:

Hi Fuelers,
we've implemented pluggable architecture piece in 6.0, and got a number
of
plugins already. Overall development process for plugins is still not
fully
defined.
We initially thought that having all the plugins in one repo on
stackforge
is Ok, we also put some docs into existing fuel-docs repo, and specs to
fuel-specs.

We might need a change here. Plugins are not tight to any particular
release
date, and they can also be separated each from other in terms of
committers
and core reviewers. Also, it seems to be pretty natural to keep all docs
and
design specs associated with particular plugin.

With all said, following best dev practices, it is suggested to:

Have a separate stackforge repo per Fuel plugin in format
"fuel-plugin-", with separate core-reviewers group which should
have
plugin contributor initially
Have docs folder in the plugin, and ability to build docs out of it

do we want Sphinx or simple Github docs format is Ok? So people can just
go
to github/stackforge to see docs

Have specification in the plugin repo

also, do we need Sphinx here?

Have plugins tests in the repo

Ideas / suggestions / comments?
Thanks,
--
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

--
Best regards,
Nick Markov


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Jan 23, 2015 by Meg_McRoberts (260 points)   1
0 votes

Hi Fuelers and Mike,

I'd like to provide some ideas/comments for the issues Mike has put into
discussion.

Yesterday we had a nice discussion for plugins SDK.

According to this discussion, we should create an internal document for
plugins certification ASAP (I mean, steps to perform on the developers'
side and assignees for the particular tasks).

So, we could also describe there (just what you've mentioned):

  • repo issue: we should definitely mention that
    stackforge/fuel-plugin- is strongly recommended for usage (we have
    some common information in Fuel Plug-in Guide, but an internal document
    should focus on that)
  • docs for plugins: I'm already working on .pdf templates for both
    Plugin Guide (how to install/configure a plugin) and Test Plan/Report
    (we'll just move to the simplest format ever, but note that this is mostly
    related to certification workflow). Nevertheless, some repos already
    contain README.md files with a brief description,
    installation/configuration instructions. For example, see Borgan D plugin's
    [1]. There is no spec, but the concept seems clear on the whole.
  • As to specification: developers should provide it in the Test Plan, so
    it would be okay if they followed one of these two ways:1) took fuel-specs
    template as the basis and simply made a link from their Test Plan/Report to
    the spec 2) post this spec right in the Test Plan/Report.
  • test in the repo: sure, this should be covered.

I believe, I'll mostly be working on this internal document, so feel free
to comment/correct me, if something seems wrong here.

[1] https://github.com/stackforge/fuel-plugins/tree/master/ha_fencing
--
--
Best regards,

Irina
-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Jan 23, 2015 by Irina_Povolotskaya (820 points)   1 2
0 votes

Hi Mike,

All of the items look nice. I have a small comment regarding to the docs.
I don't think that we should force plugin developer to write the docs in
Sphinx compatible format, I vote for Github compatible docs format,
and in case if we want to show this information somewhere else,
we can use Github's engine [1] to convert the docs into html pages.

Thanks,

[1] https://github.com/github/markup/tree/master

On Fri, Jan 23, 2015 at 1:25 AM, Mike Scherbakov
wrote:

Hi Fuelers,
we've implemented pluggable architecture piece in 6.0, and got a number of
plugins already. Overall development process for plugins is still not fully
defined.
We initially thought that having all the plugins in one repo on stackforge
is Ok, we also put some docs into existing fuel-docs repo, and specs to
fuel-specs.

We might need a change here. Plugins are not tight to any particular
release date, and they can also be separated each from other in terms of
committers and core reviewers. Also, it seems to be pretty natural to keep
all docs and design specs associated with particular plugin.

With all said, following best dev practices, it is suggested to:

  1. Have a separate stackforge repo per Fuel plugin in format
    "fuel-plugin-", with separate core-reviewers group which should have
    plugin contributor initially
  2. Have docs folder in the plugin, and ability to build docs out of it

    • do we want Sphinx or simple Github docs format is Ok? So people
      can just go to github/stackforge to see docs
  3. Have specification in the plugin repo

    • also, do we need Sphinx here?
  4. Have plugins tests in the repo

Ideas / suggestions / comments?
Thanks,
--
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Jan 23, 2015 by Evgeniy_L (8,580 points)   1 2 4
0 votes

Mike,

I also wanted to add that there is a PR already on adding plugins
repos to stackforge: https://review.openstack.org/#/c/147169/

All this looks good, but it?s not clear when this patch will be merged and repos are created.
So the question is what should we do with the current spec made in fuel-specs[1,2] which are targeted for plugins?
And how will look development process for plugins added to 6.1 roadmap?
Especially for plugins came not from external vendors and partners. Will we create separate projects on the Launchpad and duplicate our
For now I?m not sure if we need to wait for new infrastructure created in stackforge/launchpad for each plugin and follow the common
procedure to land current plugins to existing repos during 6.1 milestone.

[1] https://review.openstack.org/#/c/129586/ https://review.openstack.org/#/c/129586/
[2] https://review.openstack.org/#/c/148475/4 https://review.openstack.org/#/c/148475/4
Regards,
Alexander Ignatov

On 23 Jan 2015, at 12:43, Nikolay Markov wrote:

I also wanted to add that there is a PR already on adding plugins
repos to stackforge: https://review.openstack.org/#/c/147169/

There is a battle in comments right now, because some people are not
agree that so many repos are needed.

On Fri, Jan 23, 2015 at 1:25 AM, Mike Scherbakov
wrote:

Hi Fuelers,
we've implemented pluggable architecture piece in 6.0, and got a number of
plugins already. Overall development process for plugins is still not fully
defined.
We initially thought that having all the plugins in one repo on stackforge
is Ok, we also put some docs into existing fuel-docs repo, and specs to
fuel-specs.

We might need a change here. Plugins are not tight to any particular release
date, and they can also be separated each from other in terms of committers
and core reviewers. Also, it seems to be pretty natural to keep all docs and
design specs associated with particular plugin.

With all said, following best dev practices, it is suggested to:

Have a separate stackforge repo per Fuel plugin in format
"fuel-plugin-", with separate core-reviewers group which should have
plugin contributor initially
Have docs folder in the plugin, and ability to build docs out of it

do we want Sphinx or simple Github docs format is Ok? So people can just go
to github/stackforge to see docs

Have specification in the plugin repo

also, do we need Sphinx here?

Have plugins tests in the repo

Ideas / suggestions / comments?
Thanks,
--
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

--
Best regards,
Nick Markov


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Jan 23, 2015 by Alexander_Ignatov (760 points)   1
0 votes

Folks -

I support the idea to keep plugins' code and other artifacts, e.g. design
specs, installation and user guides, test scripts, test plan, test report,
etc, in one repo, just to create dedicated folders for that.
My argument here is pretty simple, i consider a Fuel plugin as a separate
and independent project, which should be stored in a dedicated repo and
maintained by the plugin development team.

But i don't see why we can't use Fuel Launchpad [1] to create blueprints if
we think it's necessary, but a BP itself shouldn't be a 'must do' for those
who are working on Fuel plugins.

And couple more comments:

  1. Have a separate stackforge repo per Fuel plugin in format
    "fuel-plugin-", with separate core-reviewers group which should have
    plugin contributor initially

On stackforge.
Right now there are 4 Fuel plugins developed (GlusterFS, NetApp, LBaaS,
VPNaaS) and 4 more are coming (NFS, FWaaS, Contrail, EMC VNX). Keeping in
mind that the number of Fuel plugins will grow, does it make sense to keep
them in stackforge?
Mike, Alexander, we discussed an option to keep everything in fuel-infra
[3].
I would like to hear what other folks think about that.

On the repo name.
I would suggest to add the name of OpenStack component the plugin works
with also "fuel-plugin--", e.g. fuel-plugin-cinder-emc-vnx.

  1. Have docs folder in the plugin, and ability to build docs out of it

    • do we want Sphinx or simple Github docs format is Ok? So people can
      just go to github/stackforge to see docs

I agree with Evgeniy. We are talking about best practices of Fuel plugin
development. I would prefer to keep them as simple and as easy as possible.

  1. Have specification in the plugin repo

    • also, do we need Sphinx here?
  2. Have plugins tests in the repo

So, here is how the plugin repo structure could look like:

  • fuel-plugin--
  • specs

    • plugin
    • tests
    • docs
    • utils

Alexander -

I don't think that putting these specs [4, 5] to fuel-specs [6] is a good
idea.
Let's come to an agreement, so plugin developers will know where they
should commit code,specs and other docs.

Looking forward to your comments.
Thanks.

[1] https://launchpad.net/fuel
[2] https://github.com/stackforge
[3] https://review.fuel-infra.org/
[4] https://review.openstack.org/#/c/129586/
[5] https://review.openstack.org/#/c/148475/4
[6] https://github.com/stackforge/fuel-specs

On Fri, Jan 23, 2015 at 4:14 PM, Alexander Ignatov
wrote:

Mike,

I also wanted to add that there is a PR already on adding plugins
repos to stackforge: https://review.openstack.org/#/c/147169/

All this looks good, but it?s not clear when this patch will be merged and
repos are created.
So the question is what should we do with the current spec made in
fuel-specs[1,2] which are targeted for plugins?
And how will look development process for plugins added to 6.1 roadmap?
Especially for plugins came not from external vendors and partners. Will
we create separate projects on the Launchpad and duplicate our
For now I?m not sure if we need to wait for new infrastructure created in
stackforge/launchpad for each plugin and follow the common
procedure to land current plugins to existing repos during 6.1 milestone.

[1] https://review.openstack.org/#/c/129586/
[2] https://review.openstack.org/#/c/148475/4

Regards,
Alexander Ignatov

On 23 Jan 2015, at 12:43, Nikolay Markov wrote:

I also wanted to add that there is a PR already on adding plugins
repos to stackforge: https://review.openstack.org/#/c/147169/

There is a battle in comments right now, because some people are not
agree that so many repos are needed.

On Fri, Jan 23, 2015 at 1:25 AM, Mike Scherbakov
wrote:

Hi Fuelers,
we've implemented pluggable architecture piece in 6.0, and got a number of
plugins already. Overall development process for plugins is still not fully
defined.
We initially thought that having all the plugins in one repo on stackforge
is Ok, we also put some docs into existing fuel-docs repo, and specs to
fuel-specs.

We might need a change here. Plugins are not tight to any particular
release
date, and they can also be separated each from other in terms of committers
and core reviewers. Also, it seems to be pretty natural to keep all docs
and
design specs associated with particular plugin.

With all said, following best dev practices, it is suggested to:

Have a separate stackforge repo per Fuel plugin in format
"fuel-plugin-", with separate core-reviewers group which should have
plugin contributor initially
Have docs folder in the plugin, and ability to build docs out of it

do we want Sphinx or simple Github docs format is Ok? So people can just go
to github/stackforge to see docs

Have specification in the plugin repo

also, do we need Sphinx here?

Have plugins tests in the repo

Ideas / suggestions / comments?
Thanks,
--
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

--
Best regards,
Nick Markov


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

--
Regards,
Evgeniya Shumakher
Partner Integrations Manager
Mirantis, Inc

Mob.phone: +7 (968) 760-98-42
Email: eshumakher at mirantis.com
Skype: eshumakher
-------------- next part --------------
An HTML attachment was scrubbed...
URL:

responded Jan 23, 2015 by Evgeniya_Shumakher (240 points)   1
0 votes

Hello,

I pretty much agree with Evgeniya here. Keeping everything (code, docs,
specs and tests) in the same repo is essential to keep up-to-date
information. Otherwise chances are that it will diverge eventually.
See other comments inline.

BR,

Simon

On Fri, Jan 23, 2015 at 4:50 PM, Evgeniya Shumakher <eshumakher@mirantis.com
wrote:

Folks -

I support the idea to keep plugins' code and other artifacts, e.g. design
specs, installation and user guides, test scripts, test plan, test report,
etc, in one repo, just to create dedicated folders for that.
My argument here is pretty simple, i consider a Fuel plugin as a separate
and independent project, which should be stored in a dedicated repo and
maintained by the plugin development team.

But i don't see why we can't use Fuel Launchpad [1] to create blueprints
if we think it's necessary, but a BP itself shouldn't be a 'must do' for
those who are working on Fuel plugins.

And couple more comments:

  1. Have a separate stackforge repo per Fuel plugin in format
    "fuel-plugin-", with separate core-reviewers group which should have
    plugin contributor initially

On stackforge.
Right now there are 4 Fuel plugins developed (GlusterFS, NetApp, LBaaS,
VPNaaS) and 4 more are coming (NFS, FWaaS, Contrail, EMC VNX). Keeping in
mind that the number of Fuel plugins will grow, does it make sense to keep
them in stackforge?
Mike, Alexander, we discussed an option to keep everything in fuel-infra
[3].
I would like to hear what other folks think about that.

Sounds like a good idea to use Fuel infra. From my recent experience, the
Fuel plugin framework is easy to work with and there will probably be many
plugins adding to the list. Asking for a new repository or for access right
modifications is going to be put a burden on the OpenStack infra team if it
happens too often.

On the repo name.
I would suggest to add the name of OpenStack component the plugin works
with also "fuel-plugin--", e.g.
fuel-plugin-cinder-emc-vnx.

Ok for plugins that deal with specific OpenStack services but this might
not be true for all plugins.

  1. Have docs folder in the plugin, and ability to build docs out of it

    • do we want Sphinx or simple Github docs format is Ok? So people
      can just go to github/stackforge to see docs

I agree with Evgeniy. We are talking about best practices of Fuel plugin
development. I would prefer to keep them as simple and as easy as possible.

Definitely +1.

  1. Have specification in the plugin repo

    • also, do we need Sphinx here?
  2. Have plugins tests in the repo

So, here is how the plugin repo structure could look like:

  • fuel-plugin--
  • specs

    • plugin
    • tests
    • docs
    • utils

Alexander -

I don't think that putting these specs [4, 5] to fuel-specs [6] is a good
idea.
Let's come to an agreement, so plugin developers will know where they
should commit code,specs and other docs.

Looking forward to your comments.
Thanks.

[1] https://launchpad.net/fuel
[2] https://github.com/stackforge
[3] https://review.fuel-infra.org/
[4] https://review.openstack.org/#/c/129586/
[5] https://review.openstack.org/#/c/148475/4
[6] https://github.com/stackforge/fuel-specs

On Fri, Jan 23, 2015 at 4:14 PM, Alexander Ignatov aignatov@mirantis.com
wrote:

Mike,

I also wanted to add that there is a PR already on adding plugins
repos to stackforge: https://review.openstack.org/#/c/147169/

All this looks good, but it’s not clear when this patch will be merged
and repos are created.
So the question is what should we do with the current spec made in
fuel-specs[1,2] which are targeted for plugins?
And how will look development process for plugins added to 6.1 roadmap?
Especially for plugins came not from external vendors and partners. Will
we create separate projects on the Launchpad and duplicate our
For now I’m not sure if we need to wait for new infrastructure created in
stackforge/launchpad for each plugin and follow the common
procedure to land current plugins to existing repos during 6.1 milestone.

[1] https://review.openstack.org/#/c/129586/
[2] https://review.openstack.org/#/c/148475/4

Regards,
Alexander Ignatov

On 23 Jan 2015, at 12:43, Nikolay Markov nmarkov@mirantis.com wrote:

I also wanted to add that there is a PR already on adding plugins
repos to stackforge: https://review.openstack.org/#/c/147169/

There is a battle in comments right now, because some people are not
agree that so many repos are needed.

On Fri, Jan 23, 2015 at 1:25 AM, Mike Scherbakov
mscherbakov@mirantis.com wrote:

Hi Fuelers,
we've implemented pluggable architecture piece in 6.0, and got a number of
plugins already. Overall development process for plugins is still not
fully
defined.
We initially thought that having all the plugins in one repo on stackforge
is Ok, we also put some docs into existing fuel-docs repo, and specs to
fuel-specs.

We might need a change here. Plugins are not tight to any particular
release
date, and they can also be separated each from other in terms of
committers
and core reviewers. Also, it seems to be pretty natural to keep all docs
and
design specs associated with particular plugin.

With all said, following best dev practices, it is suggested to:

Have a separate stackforge repo per Fuel plugin in format
"fuel-plugin-", with separate core-reviewers group which should have
plugin contributor initially
Have docs folder in the plugin, and ability to build docs out of it

do we want Sphinx or simple Github docs format is Ok? So people can just
go
to github/stackforge to see docs

Have specification in the plugin repo

also, do we need Sphinx here?

Have plugins tests in the repo

Ideas / suggestions / comments?
Thanks,
--
Mike Scherbakov

mihgen


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org
?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Nick Markov


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Regards,
Evgeniya Shumakher
Partner Integrations Manager
Mirantis, Inc

Mob.phone: +7 (968) 760-98-42
Email: eshumakher@mirantis.com
Skype: eshumakher


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 26, 2015 by Simon_Pasquier (2,740 points)   3 4
...