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
On Thursday, December 5, 2013 12:46:18 PM UTC-8, Michael DeHaan wrote:
>
> We will not be renaming modules for this,
> There may be some grouping in a subcategory in
> The future.
>
> -- Michael
>
> On Dec 5, 2013, at 1:00 PM, Bob Tiernay <[email protected] <javascript:>>
> wrote:
>
> 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
>
> On Tuesday, 29 October 2013 21:53:26 UTC-4, Michael DeHaan wrote:
>>
>> 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.
>>
>>
>>
>>
>> On Tue, Oct 29, 2013 at 7:01 AM, Christian Berendt <[email protected]>
>> wrote:
>>
>>> 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.
>>>
>>> Am Dienstag, 29. Oktober 2013 12:41:14 UTC+1 schrieb 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
>>>> [email protected]
>>>>
>>>> On October 29, 2013 at 4:03:29 AM, Christian Berendt (
>>>> [email protected]) wrote:
>>>>
>>>> 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.
>>>> --
>>>> 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 [email protected].
>>>>
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>> --
>>> 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 [email protected].
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>
>>
>> --
>> Michael DeHaan <[email protected]>
>> CTO, AnsibleWorks, Inc.
>> http://www.ansibleworks.com/
>>
>> --
> 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 [email protected] <javascript:>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/6f22b7dd-231e-4117-b949-d31f2fd34fba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
