# Changing quantum\_\* plugins to neutron\_\* **URL:** \ **Category:** Ansible Project\ **Created:** [October 28, 2013, 6:03am UTC](https://forum.ansible.com/t/changing-quantum-plugins-to-neutron/13786 "2013-10-28T06:03:33Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![Christian\_Berendt](https://avatars.discourse-cdn.com/v4/letter/c/ba8739/32.png) [@Christian\_Berendt](https://forum.ansible.com/u/Christian_Berendt)\ **Post date:** [October 28, 2013, 6:03am UTC](https://forum.ansible.com/t/changing-quantum-plugins-to-neutron/13786/1 "2013-10-28T06:03:33Z")
Hello together. During Grizzly and Havana the name of Quantum changed to Neutron, because of some trademark issues. At the moment the included plugins in Ansible are all called quantum\ __. I would like to change the name of all plugins to neutron\__ and also want to change the used Python module inside to python-neutronclient. mpdehaan rejected the first pull requests because of missing backward compatibility. To keep backward compatibility I suggest to simply copy the existing plugins to neutron\_\* and to do further development only in neutron\__. Older plugins (quantum\__) can be kept for some months and then they can be removed. Is that working for you, mpdehaan? Christian. ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [October 28, 2013, 12:50pm UTC](https://forum.ansible.com/t/changing-quantum-plugins-to-neutron/13786/2 "2013-10-28T12:50:46Z")
So I think we shouldn’t change the name of the modules. OpenStack is known for having a painful upgrade process, and many people may still be running Folsom deployments. The code itself could easily try / except ImportError to import both quantum or neutron client and be made to be backwards compatible. Then, maybe a release of OpenStack later or something, when it’s clear there aren’t a lot of Folsom or Essex deployments left in the wild, we could consider renaming the modules. A copy seems like a quite suboptimal for dual maintaince reasons (never a good thing) and also clutters up the module index with modules that take the same parameter lists. I’d strongly favor making them work with both versions for now, and I don’t think it’s too painful for someone to say “quantum” when they mean “neutron”, because some people will still want quantum. ---
**Author:** ![Yacine\_Kheddache](https://avatars.discourse-cdn.com/v4/letter/y/49beb7/32.png) [@Yacine\_Kheddache](https://forum.ansible.com/u/Yacine_Kheddache)\ **Post date:** [October 28, 2013, 6:34pm UTC](https://forum.ansible.com/t/changing-quantum-plugins-to-neutron/13786/3 "2013-10-28T18:34:10Z")
Just my two cents : All openstack users know that quantum is deprecated since Havana and all new features/changes will be done on behalf of neutron. Quantum will not change anymore which mean keeping the current quantum modules for “old” openstack releases and creating new neutron modules for havana and the future is IMHO cleaner and easier to follow and certainly to code/update/… 😉 ---
**Author:** ![Christian\_Berendt](https://avatars.discourse-cdn.com/v4/letter/c/ba8739/32.png) [@Christian\_Berendt](https://forum.ansible.com/u/Christian_Berendt)\ **Post date:** [October 29, 2013, 9:03am UTC](https://forum.ansible.com/t/changing-quantum-plugins-to-neutron/13786/4 "2013-10-29T09:03:27Z")
Yacine Kheddache: That’s exactly what I want to do and what I proposed in my pull request: [https://github.com/ansible/ansible/pull/4695](https://github.com/ansible/ansible/pull/4695). Michael DeHaan: Does this work for you? We keep the old modules for backward compatibility and will use the new modules (neutron\_\*) for the future. Users can then rewrite there playbooks when upgrading to Grizzly or Horizon. Christian. ---
**Author:** ![sivel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/sivel/32/1198_2.png) [@sivel](https://forum.ansible.com/u/sivel)\ **Post date:** [October 29, 2013, 11:41am UTC](https://forum.ansible.com/t/changing-quantum-plugins-to-neutron/13786/5 "2013-10-29T11:41:14Z")
I’m in agreement with Machael here. There are currently 7 quantum\_\* modules. If you duplicate them, you now have 14 modules largely for the same purpose. That really clutters up the module index. ---
**Author:** ![Christian\_Berendt](https://avatars.discourse-cdn.com/v4/letter/c/ba8739/32.png) [@Christian\_Berendt](https://forum.ansible.com/u/Christian_Berendt)\ **Post date:** [October 29, 2013, 12:01pm UTC](https://forum.ansible.com/t/changing-quantum-plugins-to-neutron/13786/6 "2013-10-29T12:01:49Z")
Then remove the quantum\_\* plugins like suggested. Quantum is deprecated. The name in the upstream is Neutron. Why should we keep the deprecated name in Ansible? For backward compatibility we could keep the quantum\_\* plugins a few weeks in the repository… And it’s not the same purpose. The quantum\_\* plugins are not longer usable with the latest release of OpenStack (Havana), because there is not longer a python-quantumclient. Only python-neutronclient… Christian. ---
**Author:** ![sivel](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/sivel/32/1198_2.png) [@sivel](https://forum.ansible.com/u/sivel)\ **Post date:** [October 29, 2013, 12:08pm UTC](https://forum.ansible.com/t/changing-quantum-plugins-to-neutron/13786/7 "2013-10-29T12:08:11Z")
Michael did make a recommendation about that. Wrap the imports in try/except and import them as a standard name in the code base. I’m not familiar enough with the clients required for this, but I would assume that the internal APIs of those clients haven’t changed much if at all in regards to a naming change. Removing them causes a backwards incompatible change for people who are using them. Copying new ones causes clutter. Having a single use code base to support both, under the previous name for backwards compatibility sounds like the best option to me. Then in a few releases, after there has been enough time to advertise the renaming, then perhaps we rename the modules themselves. ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [October 30, 2013, 1:53am UTC](https://forum.ansible.com/t/changing-quantum-plugins-to-neutron/13786/8 "2013-10-30T01:53:26Z")
It’s deprecated in a future release that not everyone is running. We are going to leave this named Quantum and I’m fine with a try/except here. It’s easy, it keeps everything working, it avoids bloating the module space. “a few weeks in the repository…” People will have live quantum deployments for another year in many cases. It’s just a name. ---
**Author:** ![Bob\_Tiernay](https://avatars.discourse-cdn.com/v4/letter/b/b3f665/32.png) [@Bob\_Tiernay](https://forum.ansible.com/u/Bob_Tiernay)\ **Post date:** [December 5, 2013, 5:27pm UTC](https://forum.ansible.com/t/changing-quantum-plugins-to-neutron/13786/9 "2013-12-05T17:27:17Z")
Why not rename all plugins to os\_\* or openstack\ __, including those of keystone\__ , nova\_\*? This avoids any future renames as well. I think it might also aid newcomers like myself that use OpenStack, but aren’t familiar with the underlying components. Cheers, Bob ---
**Author:** ![James\_Cammarata1](https://avatars.discourse-cdn.com/v4/letter/j/d26b3c/32.png) [@James\_Cammarata1](https://forum.ansible.com/u/James_Cammarata1)\ **Post date:** [December 5, 2013, 6:05pm UTC](https://forum.ansible.com/t/changing-quantum-plugins-to-neutron/13786/10 "2013-12-05T18:05:34Z")
There are two reasons we don’t generally rename existing/established modules: 1) it would break existing playbooks, and 2) because when installing with certain methods where the modules are put in a common directory, cruft may accumulate, leading to incorrect modules being used (for example, if we moved a module from one directory to another). ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [December 5, 2013, 8:46pm UTC](https://forum.ansible.com/t/changing-quantum-plugins-to-neutron/13786/11 "2013-12-05T20:46:18Z")
We will not be renaming modules for this, There may be some grouping in a subcategory in The future. – Michael ---
**Author:** ![Brad\_Crochet](https://avatars.discourse-cdn.com/v4/letter/b/8edcca/32.png) [@Brad\_Crochet](https://forum.ansible.com/u/Brad_Crochet)\ **Post date:** [December 17, 2013, 4:20pm UTC](https://forum.ansible.com/t/changing-quantum-plugins-to-neutron/13786/12 "2013-12-17T16:20:23Z")
The quantum name was changed due to a settlement on a trademark infringement. [https://answers.launchpad.net/launchpad/+question/231396](https://answers.launchpad.net/launchpad/+question/231396) The right thing to do here would be to rename the modules, but keep them backward compatible via import trickeration. Brad ---
**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:** [June 15, 2014, 7:42pm UTC](https://forum.ansible.com/t/changing-quantum-plugins-to-neutron/13786/13 "2014-06-15T19:42:21Z")
Hesitantly opening old can of worms … First of all - I couldn’t possibly agree more, renaming things is pretty awful and painful for users. I also don’t believe anything has changed this this topic was discussed six months ago regarding usage. There are still folks out there using folsom/quantum - and in fact, given the continued meteoric rise of ansible, there are almost certainly more people out there with playbooks that reference quantum\_ that would be broken by a name change than there were six month ago. But herein lies the ultimate problem - in order to avoid breaking people, which is exactly the right choice, there continue to be an increasing number of new users of a legacy name. To be clear and upfront - I don’t care specifically about the neutron/quantum naming thing itself - if I have to write things that say quantum, ok - no big deal - I’m more interested in thinking about the general upgrade/rename problem of which this is just a conveniently specific example. I’m opening my stupid mouth mainly because I’m starting to look in to re-writing a chunk of our cloud management infrastructure with ansible, because you guys have done a really great job - and I’m concerned about incurring some new technical debt. That is - if I start writing a bunch of roles and playbooks that reference quantum\_ now, and at some point in the future we may rename them, I’m putting myself in a known hole. In fact, really, there’s never going to be a good time to do that - it’s always going to suck for someone. SO - and please tell me if I’m on crack here - would you be open to adding a general ansible feature similar to aliases but for module names? That way we could more gracefully handle renames that come up allowing people a transition period. Looking at the code, there does not seem to be a good way to implement this in a perfect clean and efficient manner. The ideas I’ve come up with so far are: - symlinks. Kinda gross a little bit, but would work with no code changes. Breaks on Windows. So no. - Putting a declarative thing that’s always read in each module file. Even grosser, since it would require actually reading files to find the file to load - super slow and clunky. No. - Putting an optional declarative thing that can be searched for on module load failures. This would put the cost on anyone using an alias. Additionally, one could put this behind a config option that defaults to off - but now I’ve just described a baroque system that’s really hard to reason about. I hate all of those - but just including them for completeness. - A global extensible alias registry. The one in the tree could simply be a dict in lib/ansible/utils/plugins.py that can do a quick mapping at the top of PluginLoader.find\_plugin. Like: \_global\_aliases = { ‘neutron\_network’: ‘quantum\_network’, } # snip def find\_plugin(self, name): ‘’’ Find a plugin named name ‘’’ if name in \_global\_aliases: name = \_global\_aliases[name] That would allow the core team the ability to manage a rename over time. Additionally, one could add a configuration option that could point to a site yaml file that would allow installations to define aliases - but I actually personally don’t like that - because it has the possibility to just introduce a bunch of not-very-useful divergence in people’s playbooks. I know that people suggesting things without code are as bad as people writing code without talking to people. So I figured I just do both simultaneously and either be twice or half as bad. ) I’ve cooked up two pull requests - one that just adds the mechanism and a mapping of neutron to quantum, and another one which includes the first but also renames the modules, changes the alias order and updates the docs. [https://github.com/ansible/ansible/pull/7784](https://github.com/ansible/ansible/pull/7784) [https://github.com/ansible/ansible/pull/7785](https://github.com/ansible/ansible/pull/7785) If either of these are interesting, then awesome. If they’re not - certainly no worries, it’s been a fun morning of poking anyway. Thanks! Monty ---
**Author:** ![Ernest0x](https://avatars.discourse-cdn.com/v4/letter/e/ed655f/32.png) [@Ernest0x](https://forum.ansible.com/u/Ernest0x)\ **Post date:** [June 16, 2014, 7:49am UTC](https://forum.ansible.com/t/changing-quantum-plugins-to-neutron/13786/14 "2014-06-16T07:49:49Z")
I had not followed the thread at that time, but reading it now, I wondered why nobody had not suggested that, until I saw your proposal. Keeping backwards compatibility is good and is a must. Keeping backwards compatibility and also not forcing to use or misleading users with deprecated names or terms (or technologies) is even better. A deprecation warning is a good addition for both old and new users. ---
**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:** [June 17, 2014, 1:14am UTC](https://forum.ansible.com/t/changing-quantum-plugins-to-neutron/13786/15 "2014-06-17T01:14:08Z")
Rather than pick up code complexity for an alias feature, since this may confuse module developers - for this we’re going to just rename them at some point with a future release. I’m not positive it’s time just yet. But soon. ---
**Author:** ![Drew\_Northup](https://avatars.discourse-cdn.com/v4/letter/d/e5b9ba/32.png) [@Drew\_Northup](https://forum.ansible.com/u/Drew_Northup)\ **Post date:** [June 17, 2014, 5:13pm UTC](https://forum.ansible.com/t/changing-quantum-plugins-to-neutron/13786/16 "2014-06-17T17:13:11Z")
> Rather than pick up code complexity for an alias feature, since this may confuse module developers - for this we’re going to just rename them at some point with a future release. > > I’m not positive it’s time just yet. But soon. Looking at [http://semver.org/](http://semver.org/) (the Semantic Versioning manifesto), I’d say you’re perfectly justified in waiting until 2.x to remove things. It isn’t quite so clear that “duplicating” things is out and out bad, but it would make far more sense to introduce a “refactored” version of OpenStack modules (I’d prefer a unified block personally, instead of one for each service) as a minor point revision instead of just doing so randomly. Alas, that leaves behind the old, messy (and deprecated) piles of API calls until the next major release. It does however give the opportunity to warn people that they are using deprecated modules. SO, if everybody out there would just give Michael and his crew some space (and join the developer community), they are going to have the best chance of managing this in a sane manner. As I’ve just shown, this isn’t a cut-and-dry “only one way is right” situation. Each community needs to figure out what is right for itself. ---
**Author:** ![Ernest0x](https://avatars.discourse-cdn.com/v4/letter/e/ed655f/32.png) [@Ernest0x](https://forum.ansible.com/u/Ernest0x)\ **Post date:** [June 17, 2014, 6:10pm UTC](https://forum.ansible.com/t/changing-quantum-plugins-to-neutron/13786/17 "2014-06-17T18:10:52Z")
I think by bringing this old thread back to life, Monty wanted us not to think about the particular case with openstack modules (decisions for this have already been taken after all), but make us think about the general need of having a deprecation warning mechanism and aliasing for modules. On one hand, code complexity could possibly confuse some module developers as Michael said. On the other hand, new users could be mislead by deprecated names. In my opinion, the second is worse because it affects more people. That said, I don’t think the need for such a feature comes up often enough to give it a higher priority. ---
**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:** [June 17, 2014, 7:19pm UTC](https://forum.ansible.com/t/changing-quantum-plugins-to-neutron/13786/18 "2014-06-17T19:19:59Z")
Hi guys, Let’s not engage in meta-discussions on project governance and only discuss actual technical bits. Thread done for now.