# Deprecating pararmeters

**URL:** <https://forum.ansible.com/t/deprecating-pararmeters/15537>\
**Category:** Ansible Project\
**Created:** [June 24, 2014, 8:08pm UTC](https://forum.ansible.com/t/deprecating-pararmeters/15537 "2014-06-24T20:08:52Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Stephen\_Gargan](https://avatars.discourse-cdn.com/v4/letter/s/c67d28/32.png) [@Stephen\_Gargan](https://forum.ansible.com/u/Stephen_Gargan)\
**Post date:** [June 24, 2014, 8:08pm UTC](https://forum.ansible.com/t/deprecating-pararmeters/15537/1 "2014-06-24T20:08:52Z")

</div>

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.

---

<div class="post-metadata">

**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 25, 2014, 12:53am UTC](https://forum.ansible.com/t/deprecating-pararmeters/15537/2 "2014-06-25T00:53:24Z")

</div>

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.