Open Stack

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

-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150212/b39070c2/attachment.pgp>