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 <moh...@gmail.com> 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 ansible-proje...@googlegroups.com. >>> To post to this group, send email to ansible...@googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> >> >> -- >> Michael DeHaan <mic...@ansibleworks.com> >> 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 ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
