# We should merge OpenStack neutron\_\* modules from openstack-ansible-modules to core **URL:** \ **Category:** Ansible Developer\ **Created:** [December 5, 2014, 7:00am UTC](https://forum.ansible.com/t/we-should-merge-openstack-neutron-modules-from-openstack-ansible-modules-to-core/16969 "2014-12-05T07:00:48Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Toni\_Ylenius](https://avatars.discourse-cdn.com/v4/letter/t/f07891/32.png) [@Toni\_Ylenius](https://forum.ansible.com/u/Toni_Ylenius)\ **Post date:** [December 5, 2014, 7:00am UTC](https://forum.ansible.com/t/we-should-merge-openstack-neutron-modules-from-openstack-ansible-modules-to-core/16969/1 "2014-12-05T07:00:48Z")
Hi all, We would like to contribute on OpenStack modules but the current situation is messy as there are unofficial modules under openstack-ansible project and official modules under core. To get things moving I propose that we merge neutron\_\* modules from openstack-ansible-modules ([https://github.com/openstack-ansible/openstack-ansible-modules](https://github.com/openstack-ansible/openstack-ansible-modules)) to ansible-modules-core/cloud/openstack ([https://github.com/ansible/ansible-modules-core/tree/devel/cloud/openstack](https://github.com/ansible/ansible-modules-core/tree/devel/cloud/openstack)) In core we already have quantum\_\* modules that are out of sync with neutron\_\* modules. Overview: - 6 files to merge: neutron\_floating\_ip, neutron\_network, neutron\_router, neutron\_router\_gateway, neutron\_router\_interface, neutron\_subnet - neutron\_sec\_group is a new module and that is a different story - quantum\_floating\_ip\_asssociate doesn't have corresponding Neutron module Changes: - neutron\_floating\_ip: conflict between port\_network\_name and internal\_network\_name options - neutron\_network: vxvlan support in openstack-ansible - neutron\_router: - - neutron\_router\_gateway: - - neutron\_router\_interface: - - neutron\_subnet: core module supports subnet name, openstack-ansible module supports host\_routes I can make a crude merge without preserving the commit history. There are at least two ways to do it 1. Copy the neutron\_\* files beside the quantum\_\* files and deprecate the quantum\_\* files in the future 2. Deprecate quantum\_\* modules right away so that we have only neutron\_\* files in place So the question is, should I proceed with the plan? I'm experienced with Python, but not experienced with Ansible so I don't mind if someone else does the merge. Thanks, ---
**Author:** ![Brian\_Coca](https://avatars.discourse-cdn.com/v4/letter/b/6de8d8/32.png) [@Brian\_Coca](https://forum.ansible.com/u/Brian_Coca)\ **Post date:** [December 5, 2014, 4:16pm UTC](https://forum.ansible.com/t/we-should-merge-openstack-neutron-modules-from-openstack-ansible-modules-to-core/16969/2 "2014-12-05T16:16:49Z")
You can deprecate modules without removing them just rename them to start with an underscore (i.e. \_quantum\_network.py). This will document them as deprecated but still make them available/usable for existing playbooks. You should also update the documentation in those modules to point to the new ones that should be used instead to give users a migration path. ---
**Author:** ![Jesse\_Keating](https://avatars.discourse-cdn.com/v4/letter/j/3bc359/32.png) [@Jesse\_Keating](https://forum.ansible.com/u/Jesse_Keating)\ **Post date:** [December 5, 2014, 4:37pm UTC](https://forum.ansible.com/t/we-should-merge-openstack-neutron-modules-from-openstack-ansible-modules-to-core/16969/3 "2014-12-05T16:37:23Z")
I’m willing to work on this. I’d like to see them merged as well, and we use some of them at work, so very relevant to my interests. ccing Monty as the openstack czar. He already has some plans for what to do with the openstack modules. -jlk ---
**Author:** ![Monty\_Taylor](https://avatars.discourse-cdn.com/v4/letter/m/7993a0/32.png) [@Monty\_Taylor](https://forum.ansible.com/u/Monty_Taylor)\ **Post date:** [December 5, 2014, 10:58pm UTC](https://forum.ansible.com/t/we-should-merge-openstack-neutron-modules-from-openstack-ansible-modules-to-core/16969/4 "2014-12-05T22:58:39Z")
Hey! Sorry I’ve been slow on the draw since the OpenStack summit - I am finally on the plane on the way home right now - haven’t been there in about 6 weeks. So I owe everyone a write up of what we discussed there, what was agreed on and the overall strategy. Short version: - all modules should go into upstream ansible repo - roles and similar should be hacked on in OpenStack/stackforge repos, and we’ll add some automation to publish them to galaxy - both want to be fully integration tested in OpenStack Infra CI - as well as as much as possible in ansible’s CI (we should get double coverage that way) Module org thoughts: - modules tend to fall into two categories: - modules that are for people deploying/managing an OpenStack Cloud - modules that are for people deploying/managing workloads ON an OpenStack cloud All of them want a prefix - so os\_ or openstack\_ similar to rax\_ and gce\_ (I think most have been more interested in os\_) Things for deployers, on the other hand, should be specific - so managing a keystone tenant should really be os\_keystone\_tenant - because guess what, you’re the deployer, you DO need to know what implementation choices you’ve made. There are currently three sets of modules in three different places that are working on this: - [http://git.openstack.org/cgit/stackforge/os-ansible-deployment/](http://git.openstack.org/cgit/stackforge/os-ansible-deployment/) - [https://github.com/openstack-ansible/openstack-ansible-modules](https://github.com/openstack-ansible/openstack-ansible-modules) - [https://github.com/blueboxgroup/ursula](https://github.com/blueboxgroup/ursula) Before we suck any of these into ansible itself, we need to align on what we want the strategy to be, if any, in terms of convergence (there isn’t consensus on the topic, so blessing one in the ansible tree itself seems rather premature - but everyone in Paris seemed keen on reaching consensus) There’s going to be at least some pain all the way around no matter which direction we go because of the intent to prefix openstack things in the ansible tree - so ursula’s cinder\_volume\_group will want to become os\_cinder\_volume\_group. Things for end-consumers should not use code names, but should reference the concept. So, to spin up a vm, one would expect to use os\_compute rather than os\_nova. This allows for some richer implementation flexibility for things like images that might be able to use glance directly or might have to go through nova and that a user should not really need to care about. It also allows us to avoid getting screwed by name changes brought on by trademark issues. So far the list of openstack projects where this has happened is quantum/neutron, moniker/designate, reddwarf/trove and savana/sahara. We can also take advantage of the new aliasing feature in 1.8, but let’s just do it cleanly in the first place since these are the most likely to be used by sets of people not following the internal politics of OpenStack. Initial reworkings with that in mind are up for review on extras, but it would be great to get a few more people to bang on them before we merge them: [https://github.com/ansible/ansible-modules-extras/pull/92](https://github.com/ansible/ansible-modules-extras/pull/92) There were a couple of attempts to do this by morphing the old ones, but the structure of them was such that the code providing compatability with an old model (no keystone v3, no support for multi-cloud, etc) got so hariy so quickly that a clean break and a deprecation of the existing modules was discussed as the cleanest way forward. SO - the new modules should keep in mind that ansible has much stronger backwards compat stances than OpenStack upstream and need to be done with flexibility and the future in mind. We’ll carry the cost of maintenance of the old deprecated ones for a good while so that no one gets screwed. I will be actively hacking on this again this weekend now that I’ll finally be home - but I’d REALLY love to crank on this with other folks. There is an #openstack-ansible channel where folks are hacking on stackforge/os-ansible-deployment When I’m not crammed in a tiny seat on a plane, I’ll write this all up on a wiki to make sure we’re all good to go. Monty ---
**Author:** ![Jesse\_Keating](https://avatars.discourse-cdn.com/v4/letter/j/3bc359/32.png) [@Jesse\_Keating](https://forum.ansible.com/u/Jesse_Keating)\ **Post date:** [December 5, 2014, 11:22pm UTC](https://forum.ansible.com/t/we-should-merge-openstack-neutron-modules-from-openstack-ansible-modules-to-core/16969/5 "2014-12-05T23:22:00Z")
Thanks Monty! I’ll be part of the fun. - jlk ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [December 6, 2014, 2:02am UTC](https://forum.ansible.com/t/we-should-merge-openstack-neutron-modules-from-openstack-ansible-modules-to-core/16969/6 "2014-12-06T02:02:07Z")
For reminders to those new to the thread, I have given Monty commit on the module repos and he’s “owner” on these puppies. If we do develop alternative modules we need to deprecate the old ones by renaming them to start with “\_” and adding the “deprecated: this is why this is deprecated” message to the module DOCUMENTATION doctoring in each module. I’m happy to do whatever, and then we would plan on removing the deprecated versions in 1 or 2 releases. We could also move the stuff in “/openstack” to “/openstack\_legacy” to make it even more clear in the “cloud” module lists in the doc sections. ---
**Author:** ![Toni\_Ylenius](https://avatars.discourse-cdn.com/v4/letter/t/f07891/32.png) [@Toni\_Ylenius](https://forum.ansible.com/u/Toni_Ylenius)\ **Post date:** [December 8, 2014, 7:27am UTC](https://forum.ansible.com/t/we-should-merge-openstack-neutron-modules-from-openstack-ansible-modules-to-core/16969/7 "2014-12-08T07:27:18Z")
Good to hear that there is a plan. As a newcomer I will step aside and watch the progress, but I'm glad to help if you see my input valuable. I’m more interested in os\_\* modules rather than generic modules. Next question, If I have something to contribute on a module that exist in all of the two/three/four repositories, should I 1. push to one of these or 2. wait for the refactoring? Thanks, ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [December 8, 2014, 3:45pm UTC](https://forum.ansible.com/t/we-should-merge-openstack-neutron-modules-from-openstack-ansible-modules-to-core/16969/8 "2014-12-08T15:45:26Z")
I believe in OpenStack land the best thing to do would be to wait just a bit, as investment in the existing tree might not be applied going forward. If you ever need to submit something to module\_utils, I would submit that first and then link in the other PRs (in the other repo) to the dependent pull requests. ---
**Author:** ![Lorin\_Hochstein](https://avatars.discourse-cdn.com/v4/letter/l/5f9b8f/32.png) [@Lorin\_Hochstein](https://forum.ansible.com/u/Lorin_Hochstein)\ **Post date:** [December 14, 2014, 4:39am UTC](https://forum.ansible.com/t/we-should-merge-openstack-neutron-modules-from-openstack-ansible-modules-to-core/16969/9 "2014-12-14T04:39:49Z")
Hey Monty: I’m a maintainer of the [https://github.com/openstack-ansible/openstack-ansible-modules](https://github.com/openstack-ansible/openstack-ansible-modules) repo. I don’t actively hack on it these days, but I do merge in pull requests, and we still get some coming in. Happy to help in any way I can in this effort. Take care, Lorin ---
**Author:** ![Toni\_Ylenius](https://avatars.discourse-cdn.com/v4/letter/t/f07891/32.png) [@Toni\_Ylenius](https://forum.ansible.com/u/Toni_Ylenius)\ **Post date:** [December 15, 2014, 2:26pm UTC](https://forum.ansible.com/t/we-should-merge-openstack-neutron-modules-from-openstack-ansible-modules-to-core/16969/10 "2014-12-15T14:26:56Z")
Hi, Is there something I can help you with? I would like to commit the changes to upstream and I have three modules waiting already: neutron\_port, keystone\_group and nova\_quota. I see that there is an ambitious plan to make the code better and I agree that codebase needs major rework, but is there a small step where we could start? Waiting will rot code in all the repositories. For example, can you provide an example of ideal module. Using the example file we can refactor modules to follow the new guidelines and push them to core. Thanks, ---
**Author:** ![Monty\_Taylor](https://avatars.discourse-cdn.com/v4/letter/m/7993a0/32.png) [@Monty\_Taylor](https://forum.ansible.com/u/Monty_Taylor)\ **Post date:** [December 17, 2014, 3:40pm UTC](https://forum.ansible.com/t/we-should-merge-openstack-neutron-modules-from-openstack-ansible-modules-to-core/16969/11 "2014-12-17T15:40:38Z")
Absolutely! The second two definitely sound like deployer/admin modules, right? So first step I’d rename them to os\_keystone\_group and os\_nova\_quota. The first one, neutron\_port, seems like something that a cloud end user would use, so let’s call that os\_port or os\_network\_port. (see below for a question) There is a pull with a bunch of modules in it: [https://github.com/ansible/ansible-modules-extras/pull/92](https://github.com/ansible/ansible-modules-extras/pull/92) You’ll see that they share various amount of things.such as using the openstack documentation fragment, openstack\_argument\_spec and the get the cloud connections and client objects through the shade library: cloud = shade.openstack\_cloud(\*\*module.params) I’m using these modules right now myself, so in some senses they’re “ready” - but what would be really useful is a few more eyes or hands on them. j2sol, for instance, just made a great point about server name being the idempotence key - so banging against these in anger would be fantastic so that we can make sure we’re not painting ourselves into a corner with them. FOR INSTANCE: these modules have os\_network, os\_router\_interface, os\_router\_gateway and os\_subnet. Looking at neutron\_port - do we think that should be os\_port? or os\_network\_port. If it’s os\_network\_port, would that mean we think that os\_subnet needs to be os\_network\_subnet? (that seems silly, but os\_port seems a bit overly generic maybe) I don’t think we need a taxonomy per-se, but I’d love opinions from humans who are not me. Sorry for the long delay on this one - I agree, let’s get it tied off and move forward.