Deprecating pararmeters

[Stephen Gargan]

Hi,

I've been making changes to the ec2_elb_lb module to allow security group names as well as security group ids. While doing this I had added a new module parameter 'security_groups' with the intention of marking the id specific one as deprecated. I was wondering how this kind of deprecation should be handled? I'd thought to use the deprecated function in display_functions.py but because this is called at runtime in the target machine it gets swallowed.

Looking around the codebase, there are only a few module parameters currently deprecated, but its likely to be more and more useful. It would be pretty simple to gather deprecated messages (or other warnings for that matter) and return these with the exit_json or fail_json where they could be deduped and displayed. 

What are peoples thoughts on this? 

thanks,

Steve.

[Michael DeHaan]

Sounds like a good topic for ansible-devel BTW.

Anyway, we generally try to avoid deprecating *any* parameters, I'd be interested in references to specifics you've found as I don't recall them offhand.

I think the first question should be do we need to deprecate this at all, with the default of the conversation always erring to "not unless we absolutely have to".

I don't feel we need to return this in verbose data, as many times this is not viewed.

--
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/4f60fece-5631-4f10-ae4e-2188a3b29912%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.