Changing quantum_* plugins to neutron_*

[Christian Berendt]

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.

[Michael DeHaan]

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.

 

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

[Yacine Kheddache]

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/... ;-) 

[Christian Berendt]

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.

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.

[Matt Martz]

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.

-- 
Matt Martz
ma...@sivel.net

[Christian Berendt]

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.

[Matt Martz]

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.

-- 
Matt Martz
ma...@sivel.net

[Michael DeHaan]

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.

[Bob Tiernay]

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

[James Cammarata]

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).

James Cammarata <jcamm...@ansibleworks.com>
Sr. Software Engineer, AnsibleWorks, Inc.
http://www.ansibleworks.com/

[Michael DeHaan]

We will not be renaming modules for this,

There may be some grouping in a subcategory in

The future.

-- Michael

[Brad Crochet]

The quantum name was changed due to a settlement on a trademark infringement.

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

[Monty Taylor]

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/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

[Petros Moisiadis]

On 06/15/2014 10:42 PM, Monty Taylor wrote:
> ...

> 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.

> ...

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.

[Michael DeHaan]

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.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.

To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/539EA19D.1070606%40yahoo.gr.

For more options, visit https://groups.google.com/d/optout.

[Drew Northup]

On Monday, June 16, 2014 9:14:17 PM UTC-4, Michael DeHaan wrote:

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/ (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.

[Petros Moisiadis]

On 06/17/14 20:13, Drew Northup wrote:

On Monday, June 16, 2014 9:14:17 PM UTC-4, Michael DeHaan wrote:

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/ (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.

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.

On Mon, Jun 16, 2014 at 2:49 AM, 'Petros Moisiadis' via Ansible Project <ansible...@googlegroups.com> wrote:

On 06/15/2014 10:42 PM, Monty Taylor wrote:
> ...

> 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.

> ...

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.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/539EA19D.1070606%40yahoo.gr.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/7bd6c470-b2d5-4f53-87d0-c988cd93cf3c%40googlegroups.com.

[Michael DeHaan]

Hi guys,

Let's not engage in meta-discussions on project governance and only discuss actual technical bits.

Thread done for now.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/53A084AC.6090709%40yahoo.gr.