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
