Re: [openstack-dev] [devstack] [third-party] how to use a devstack external plugin in gate testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Following the conversation... We have seen that glusterfs[1] and ec2api[2] use different approach when it comes to repository managing: whereas glusterfs is a single 'devstack' directory repository, ec2api is a whole project with a 'devstack' directory on it. We plan to migrate 'python-neutron-plugin-midonet'[3] project to Stackforge too. It makes sense to add the 'devstack' directory on it? Or do you recommend us to have two different repositories in Stackforge: one for the neutron plugin and the other one for the devstack plugin? We can not see any big advantage or disadvantage in any of them... so we have decided to ask to the community if someone is able see what we can not see. Regards, [1]: https://github.com/stackforge/devstack-plugin-glusterfs [2]: https://github.com/stackforge/ec2-api [3]: https://github.com/midonet/python-neutron-plugin-midonet El 11/02/15 a las 17:43, Jaume Devesa escribió: Hello, I'm working in the same job as Kyle for the midonet plugin, but first I need to do some changes in devstack. (Sean's review on my patch[1] has lead me to this conversation). After talking with Lucas, (Midokura's responsible of Third-party testing), we have a question about this that involve the third-party folks: if we get our own Jenkins job that tests devstack with midonet and we include this job in the Neutron's gate (as non-voting, of course), that would be considered Neutron Third-party testing? Can we chat about this on next Monday's third party meeting? Regards, [1]: https://review.openstack.org/#/c/152876 El 06/02/15 a las 22:54, Kyle Mestery escribió: On Fri, Feb 6, 2015 at 1:36 PM, Sean Dague s...@dague.net wrote: For those that didn't notice, on the Devstack team we've started to push back on new in-tree support for all the features. That's intentional. We've got an external plugin interface now - http://docs.openstack.org/developer/devstack/plugins.html#externally-hosted-plugins , and have a few projects like the ec2api and glusterfs that are successfully using it. Our Future direction is to do more of this - https://review.openstack.org/#/c/150789/ The question people ask a lot is 'but, how do I do a gate job with the external plugin?'. Starting with the stackforge/ec2api we have an example up on how to do that: https://review.openstack.org/#/c/153659/ The important bits are as follows: 1. the git repo that you have your external plugin in *must* be in gerrit. stackforge is fine, but it has to be hosted in the OpenStack infrastructure. 2. The job needs to add your PROJECT to the projects list, i.e.: export PROJECTS=stackforge/ec2-api $PROJECTS 3. The job needs to add a DEVSTACK_LOCAL_CONFIG line for the plugin enablement: export DEVSTACK_LOCAL_CONFIG=enable_plugin ec2-api git://git.openstack.org/stackforge/ec2-api Beyond that you can define your devstack job however you like. It can test with Tempest. It can instead use a post_test_hook for functional testing. Whatever is appropriate for your project. This is awesome Sean! Thanks for the inspiration here. In fact, I just pushed a series of patches [1] [2] which do the same for the networking-odl stackforge project. Thanks, Kyle [1] https://review.openstack.org/#/c/153704/ [2] https://review.openstack.org/#/c/153705/ -Sean -- Sean Dague http://dague.net __ 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 - -- Jaume Devesa Software Engineer, Midokura -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU3IopAAoJEPvO/ogkgqHBRRIP/0PcoPvFBBOg+TdWLGQFS7jf 4cgPe+PAnUFUtaEn78YTYSp5UkK6TzDEA9I0TqD88a2MK7rP+x0XAxtlTBRpIB0s AbSIJd6Eg0GCnqdPxztzeRcxagr+oTSys79cYd49JWMBfUYgCDjdQBYHq5IacvgM PG/8EiHWdQAo1nmxXQhy18p7+nMnntt0BBkLBwFPFmo/QnjCqveN0bvHSCcIhLRv heVnK/clvPzeyx+5tRT67dEmaP0X+xtSdA2Y/HNJIwUl1m6Z6L9JwIyuffHi/py5 GUxScogIHjids4i9IU+EmO/ltrfwZ/Kad5EjareSSPenvuv0Bk78RiYGUhBjvwdw CrnlK6fCq5SACtw47kgWMyc1UM+Y5gIw/DguX1eQjaKXtr2Mzp0ij4p/Swi5Meo+ Q09tsKbcNWKDtDUiwmKWTkuhe1+V3iYwLARivs7DygthHWaAs2JnDwPiLO/L07i/ dGVel6hrwsHmIJGafLyxGD8pVeFcIHOx0Bc8/AxzybH8Un8kokwNmTMqfZwthWOK Az61ofATI53+lDy6jo9ilcm1FNifuUhOekRJqBhyEzJqd5ZZwtGCI1sJv5YGanA/ GYAFGPP0noL+nnavQoEbIjrlurXrYX7Rb5AZT643KSuerMy29J7ReChcuV9olkZd bqQ3f1PqIv/ZUx+qVvHu =45Da -END PGP SIGNATURE-
Re: [openstack-dev] [devstack] [third-party] how to use a devstack external plugin in gate testing
On 02/12/2015 06:10 AM, Jaume Devesa wrote: Following the conversation... We have seen that glusterfs[1] and ec2api[2] use different approach when it comes to repository managing: whereas glusterfs is a single 'devstack' directory repository, ec2api is a whole project with a 'devstack' directory on it. We plan to migrate 'python-neutron-plugin-midonet'[3] project to Stackforge too. It makes sense to add the 'devstack' directory on it? Yes, the intent was always to put the devstack directory inside existing git trees that you would want to clone to add to your devstack environment. Or do you recommend us to have two different repositories in Stackforge: one for the neutron plugin and the other one for the devstack plugin? We can not see any big advantage or disadvantage in any of them... so we have decided to ask to the community if someone is able see what we can not see. I believe in your case if you *don't* do it this way, your devstack plugin would then need to clone your 'python-neutron-plugin-midonet' git tree. Which is kind of janky. It also *won't* work in the OpenStack CI system. The reason 'devstack-plugin-glusterfs' is done that way is because there is no other active git trees for glusterfs support. Glusterfs driver support is in the main Cinder tree - https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/glusterfs.py. For projects with a vast array of in tree drivers, doing this as a dedicated stackforge project per driver is probably best practice. However, in the neutron case where the drivers are out to tree, I believe putting the devstack support in the driver tree is best practice. -Sean Regards, [1]: https://github.com/stackforge/devstack-plugin-glusterfs [2]: https://github.com/stackforge/ec2-api [3]: https://github.com/midonet/python-neutron-plugin-midonet El 11/02/15 a las 17:43, Jaume Devesa escribió: Hello, I'm working in the same job as Kyle for the midonet plugin, but first I need to do some changes in devstack. (Sean's review on my patch[1] has lead me to this conversation). After talking with Lucas, (Midokura's responsible of Third-party testing), we have a question about this that involve the third-party folks: if we get our own Jenkins job that tests devstack with midonet and we include this job in the Neutron's gate (as non-voting, of course), that would be considered Neutron Third-party testing? Can we chat about this on next Monday's third party meeting? Regards, [1]: https://review.openstack.org/#/c/152876 El 06/02/15 a las 22:54, Kyle Mestery escribió: On Fri, Feb 6, 2015 at 1:36 PM, Sean Dague s...@dague.net wrote: For those that didn't notice, on the Devstack team we've started to push back on new in-tree support for all the features. That's intentional. We've got an external plugin interface now - http://docs.openstack.org/developer/devstack/plugins.html#externally-hosted-plugins , and have a few projects like the ec2api and glusterfs that are successfully using it. Our Future direction is to do more of this - https://review.openstack.org/#/c/150789/ The question people ask a lot is 'but, how do I do a gate job with the external plugin?'. Starting with the stackforge/ec2api we have an example up on how to do that: https://review.openstack.org/#/c/153659/ The important bits are as follows: 1. the git repo that you have your external plugin in *must* be in gerrit. stackforge is fine, but it has to be hosted in the OpenStack infrastructure. 2. The job needs to add your PROJECT to the projects list, i.e.: export PROJECTS=stackforge/ec2-api $PROJECTS 3. The job needs to add a DEVSTACK_LOCAL_CONFIG line for the plugin enablement: export DEVSTACK_LOCAL_CONFIG=enable_plugin ec2-api git://git.openstack.org/stackforge/ec2-api Beyond that you can define your devstack job however you like. It can test with Tempest. It can instead use a post_test_hook for functional testing. Whatever is appropriate for your project. This is awesome Sean! Thanks for the inspiration here. In fact, I just pushed a series of patches [1] [2] which do the same for the networking-odl stackforge project. Thanks, Kyle [1] https://review.openstack.org/#/c/153704/ [2] https://review.openstack.org/#/c/153705/ -Sean -- Sean Dague http://dague.net __ 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] [devstack] [third-party] how to use a devstack external plugin in gate testing
Jaume Devesa devv...@gmail.com writes: Following the conversation... We have seen that glusterfs[1] and ec2api[2] use different approach when it comes to repository managing: whereas glusterfs is a single 'devstack' directory repository, ec2api is a whole project with a 'devstack' directory on it. We plan to migrate 'python-neutron-plugin-midonet'[3] project to Stackforge too. It makes sense to add the 'devstack' directory on it? Or do you recommend us to have two different repositories in Stackforge: one for the neutron plugin and the other one for the devstack plugin? as you stated I don't think there is a clear advantage or disadvantage but IMO having too many repositories is not very user friendly and I would recommend to have the plugin directly in the repo. For things like glusterfs which is not a native openstack project it makes sense that the plugin is hosted externally of the project. Chmouel __ 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] [devstack] [third-party] how to use a devstack external plugin in gate testing
On 2/12/15, 1:33 PM, Chmouel Boudjnah chmo...@enovance.com wrote: Jaume Devesa devv...@gmail.com writes: Following the conversation... We have seen that glusterfs[1] and ec2api[2] use different approach when it comes to repository managing: whereas glusterfs is a single 'devstack' directory repository, ec2api is a whole project with a 'devstack' directory on it. We plan to migrate 'python-neutron-plugin-midonet'[3] project to Stackforge too. It makes sense to add the 'devstack' directory on it? Or do you recommend us to have two different repositories in Stackforge: one for the neutron plugin and the other one for the devstack plugin? as you stated I don't think there is a clear advantage or disadvantage but IMO having too many repositories is not very user friendly and I would recommend to have the plugin directly in the repo. For things like glusterfs which is not a native openstack project it makes sense that the plugin is hosted externally of the project. I am in favor of having these in the devstack reop. I think that keeping everything under the same umbrella is the healthiest model. Moving things to different repos is a a challenge and leads to endless problems (that is my two cents) Chmouel __ 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] [devstack] [third-party] how to use a devstack external plugin in gate testing
Sean Dague s...@dague.net writes: I'm going to be -1ing most new or substantially redone drivers at this point. External plugins are a better model for those. +1 Chnmouel __ 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] [devstack] [third-party] how to use a devstack external plugin in gate testing
On 02/12/2015 07:49 AM, Gary Kotton wrote: On 2/12/15, 1:33 PM, Chmouel Boudjnah chmo...@enovance.com wrote: Jaume Devesa devv...@gmail.com writes: Following the conversation... We have seen that glusterfs[1] and ec2api[2] use different approach when it comes to repository managing: whereas glusterfs is a single 'devstack' directory repository, ec2api is a whole project with a 'devstack' directory on it. We plan to migrate 'python-neutron-plugin-midonet'[3] project to Stackforge too. It makes sense to add the 'devstack' directory on it? Or do you recommend us to have two different repositories in Stackforge: one for the neutron plugin and the other one for the devstack plugin? as you stated I don't think there is a clear advantage or disadvantage but IMO having too many repositories is not very user friendly and I would recommend to have the plugin directly in the repo. For things like glusterfs which is not a native openstack project it makes sense that the plugin is hosted externally of the project. I am in favor of having these in the devstack reop. I think that keeping everything under the same umbrella is the healthiest model. Moving things to different repos is a a challenge and leads to endless problems (that is my two cents) I believe the question was really should the devstack plugin be in 'python-neutron-plugin-midonet' repo or in an additional 'python-neutron-plugin-midonet-devstack' repo. Being in the main devstack tree was never on the table. I -1ed that review and sent them down this path. The Long Term Evolution for Devstack is external plugins for most things - https://github.com/openstack-dev/devstack/blob/master/FUTURE.rst I'm going to be -1ing most new or substantially redone drivers at this point. External plugins are a better model for those. -Sean -- Sean Dague http://dague.net __ 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] [devstack] [third-party] how to use a devstack external plugin in gate testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, I'm working in the same job as Kyle for the midonet plugin, but first I need to do some changes in devstack. (Sean's review on my patch[1] has lead me to this conversation). After talking with Lucas, (Midokura's responsible of Third-party testing), we have a question about this that involve the third-party folks: if we get our own Jenkins job that tests devstack with midonet and we include this job in the Neutron's gate (as non-voting, of course), that would be considered Neutron Third-party testing? Can we chat about this on next Monday's third party meeting? Regards, [1]: https://review.openstack.org/#/c/152876 El 06/02/15 a las 22:54, Kyle Mestery escribió: , OpenStack Development Mailing List (not for usage questions) OpenStack Development Mailing List (not for usage questions) - -- Jaume Devesa Software Engineer, Midokura -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU24bCAAoJEPvO/ogkgqHBFvMQAJAQM83wgOr6WIcRr3hOZthd d82JVjXRdY282hvu2Eid+n47RdEfwBTbRkJnnKyWW9IcxsO8HX3oEjPct4H33CCB c8kjQUile7WVQZt2obAT+PMwbub9u1/WTxnzUIUujg6NhKoXmM+f5lEawCh6k1HZ UqiTIb+8P08m+IhOIAjG95lTENSAX9P4YJA48vTDLtyODYo6kuWYh1TVx5IxvpnU Min1xMcxYr2mPNZv1P9Hu+cOx9g1ZDPvUEXe03lzR4HqFkisXe2Xi8OK+J778KyT xCSGoJ19x3pcuDIqUy2LQ5wgv41vuQtd5ASJLx7oaXk/Bsr1CRv6NSK1zYb7zA/C As4bTwpZQqKCnRfYVrys8cDWS2ZVGH1APQT7AhVL8CnluLPTMwjrbNRzv3gYi5kU CPh0aGTdt9hsi061k7Th/A2Op7Zz6MAT3fWjscJYSftdX0g+l/UYGpUHCoagynew KKkNS2BfM1AIvTpyC2zKeV/u53Oup1+htkV+rc8TMHXIztpbvxWVdG/BP9sao2xC iIFPjkyaL4ZyG20O0R5NzR0gYxjZMutRbxl2iyC8fpLOJRY1DosOg7he3htgAM45 J7VPZp41cW8CmR//2G8hinBC+cW6SZzhNeOogzT89KEn/a0KV5SoMxCy0oLfaDR7 upfUpAWAO1vIgl53ftFj =yUo7 -END PGP SIGNATURE- __ 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] [devstack] [third-party] how to use a devstack external plugin in gate testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, I'm working in the same job as Kyle for the midonet plugin, but first I need to do some changes in devstack. (Sean's review on my patch[1] has lead me to this conversation). After talking with Lucas, (Midokura's responsible of Third-party testing), we have a question about this that involve the third-party folks: if we get our own Jenkins job that tests devstack with midonet and we include this job in the Neutron's gate (as non-voting, of course), that would be considered Neutron Third-party testing? Can we chat about this on next Monday's third party meeting? Regards, [1]: https://review.openstack.org/#/c/152876 El 06/02/15 a las 22:54, Kyle Mestery escribió: On Fri, Feb 6, 2015 at 1:36 PM, Sean Dague s...@dague.net wrote: For those that didn't notice, on the Devstack team we've started to push back on new in-tree support for all the features. That's intentional. We've got an external plugin interface now - http://docs.openstack.org/developer/devstack/plugins.html#externally-hosted-plugins , and have a few projects like the ec2api and glusterfs that are successfully using it. Our Future direction is to do more of this - https://review.openstack.org/#/c/150789/ The question people ask a lot is 'but, how do I do a gate job with the external plugin?'. Starting with the stackforge/ec2api we have an example up on how to do that: https://review.openstack.org/#/c/153659/ The important bits are as follows: 1. the git repo that you have your external plugin in *must* be in gerrit. stackforge is fine, but it has to be hosted in the OpenStack infrastructure. 2. The job needs to add your PROJECT to the projects list, i.e.: export PROJECTS=stackforge/ec2-api $PROJECTS 3. The job needs to add a DEVSTACK_LOCAL_CONFIG line for the plugin enablement: export DEVSTACK_LOCAL_CONFIG=enable_plugin ec2-api git://git.openstack.org/stackforge/ec2-api Beyond that you can define your devstack job however you like. It can test with Tempest. It can instead use a post_test_hook for functional testing. Whatever is appropriate for your project. This is awesome Sean! Thanks for the inspiration here. In fact, I just pushed a series of patches [1] [2] which do the same for the networking-odl stackforge project. Thanks, Kyle [1] https://review.openstack.org/#/c/153704/ [2] https://review.openstack.org/#/c/153705/ -Sean -- Sean Dague http://dague.net __ 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 - -- Jaume Devesa Software Engineer, Midokura -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU24bCAAoJEPvO/ogkgqHBpKMP/0aQoCNgQs/8w8gDjmUxlzI4 BE3e3+bGPKKwBNusc6N1i7ptoqz9WU+Atl38uOvxYabFYig94l639tJxTUQGOGQ8 mSYdq+MNMqr/ExKp2M5SQr4QNeMlB8TqqBTdzwH+HIhNu4Het8aybwlLo4O2XBFQ zFPVtLCxd9d3LlTyTztHg0oQ2U4vZDwdSLyVytFFrq9orjXFKAl6JRIssR9Kf4t4 Raxm2KTjbukxmo/4jwhJl9c1Cm/y+RmRinyXIrh0ppglP80xaIp0RljqhY3UEQRu ifgcxEod7HZNTHeTksg7QFMiiT1PO/32fOQPgJbZhX2siAQan3xajcC5g0sDZtoM 3OrhDf9mk6WH/6QkKs235z3HqjWJGEsE5TLGeTHsFA4Je2z45Jn9tT7WJWmvMZiK wiSHd1NxpIKc+PY7STlcvzZZKmEDg8wyXL+VFdGg5RF1SV9Dmp3PeDcQ8RqyrNLL myWPC2ZGpWxueD12hQay8WJ8WOLWn/ei0NVmHXhkxZqG+X2s3Ya/cfp1CpIVigpJ WcqlHtqPHvD4sISATY/qqT4ZPi4NY06fh0IxJ+qfXyn8pOJcpcwjiygS85iWRgEK 4rq/FNYymtpJdDJjpA0eL3DVfffYocCMKos6QIg7aIOvNY9QMzpakRe4BCRzXviA 4Vkp7Dze/fQjdDovnIec =gbvT -END PGP SIGNATURE- __ 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
