Don't mean to bug (pun intended) - but I am pretty keen on getting a fix 
for this in. 

What do you think would be the best way forward ? If you feel the concern I 
raise is not really valid, I am fine creating a pull request for a diff 
that solely supresses any subnet value when doing a command="modify"

Thanks!

Mohan

On Thursday, 26 December 2013 10:47:49 UTC+8, Mohan Krishnan wrote:
>
> Although that would work, it might lead to folks setting the subnet 
> argument and expecting to actually have an effect, but if we are just 
> dropping it off - you would have successful runs without the expected 
> result. We could probably add a warning message, but this also changes how 
> invalid arguments are dealt with in all other cases (It errors out). 
>
> Having said that, I am keen on getting this fixed soon, so if we are ok 
> with the above concerns, I'll make the necessary changes to the pull 
> request and resubmit.
>
>
> On Tuesday, 24 December 2013 00:58:18 UTC+8, Michael DeHaan wrote:
>>
>> Seems like the solution is to not send the "subnet" parameter when it's 
>> going to be invalid?
>>
>>
>>
>>
>> On Sun, Dec 22, 2013 at 7:53 AM, Mohan Krishnan <[email protected]> wrote:
>>
>>> Hello,
>>>
>>> The code relies on the "subnet" argument  being set to determine if the 
>>> RDS instance is within a VPC. If it is, it switches the "security_groups" 
>>> argument (when provided) from security_groups to vpc_security_groups in 
>>> the underlying boto call. This works fine for the command=create case.
>>>
>>> However in the command=modify case, the "subnet" argument is considered 
>>> invalid (As the AWS API  does not allow for subnet modification of a  
>>> provisioned 
>>> instance). This results in the security_groups parameter always being 
>>> treated 
>>> as  a non-VPC security group, even when it is.
>>>
>>> The underlying boto library uses two separate  arguments for when the 
>>> security group is part of a vpc (vpc_security_groups) and for when it 
>>> is not (security_groups). I feel replicating this separation is probably 
>>> the simplest and most  explicit way of solving this issue.
>>>
>>> This pull request implements the separation - 
>>> https://github.com/ansible/ansible/pull/5389
>>>
>>> The downside is it does introduce a backward incompatible change to the 
>>> arguments if you use a VPC based rds. Instead of using security_groups you 
>>> will now need to use vpc_security_groups. 
>>>
>>> What do you guys think ?
>>>
>>> Mohan
>>>  
>>> -- 
>>> 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].
>>> 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].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to