Updated this PR, added state='allocate' option, and fixed logic that looks for free elastic IPs that aren't currently associated with an instance.
On Tuesday, November 11, 2014 12:05:44 PM UTC-5, Herby Gillot wrote: > > 1) I personally think that if no public IP is specified, but an instance > ID is provided, then nothing should be done if that instance already has an > elastic IP attached to it. > > 2) If we want to simply allocate a new Elastic IP, then I agree that that > should simply be a new state flag, state='allocate', as Micheal suggested. > > To that end, the following pull request addresses ( > https://github.com/ansible/ansible-modules-core/pull/300 ). It should > probably be followed up another PR that adds an 'allocate' state for 2. > > On Tuesday, November 11, 2014 7:56:36 AM UTC-5, Eoin Verling wrote: >> >> Agree with Ananda ... precisely what I did. >> >> I noticed I was running out of EIPs, each call created a new one but >> didn't associate it (as the instance already had one!) ... so I just added >> a "when" the instance.public_ip == none ... works like a charm >> >> e >> >> On Friday, 31 October 2014 04:24:15 UTC, Ananda Debnath wrote: >>> >>> I agree with Michael on the variable expectations on idempotency here. >>> >>> Is the command 'date' idempotent? It can be invoked with no arguments >>> and almost always *returns* a different value - but results in no >>> *perceivable >>> state change on the system* where the command was called. >>> What about the 'touch' command? It takes an argument, always 'does the >>> same thing' (update mtime to 'now' whatever the value of now may be)... >>> results in a *perceivable *state change. >>> If "now" is viewed as a relative constant, the result of this action on >>> the system is idempotent in spirit. If the absolute value of time is the >>> constant in mind, then it's never idempotent - even in spirit. >>> It's a slippery slope :) >>> >>> In this specific case, I think the spirit would be better served if: >>> >>> 1. You could query the instance to check whether or not it had an >>> EIP allocated to it >>> 2. Use the results of the query and express it as a 'when' condition >>> that triggered or skipped the eip command. If you had a specific EIP in >>> mind, then the when condition could be expressed as an equality with the >>> specific EIP as well >>> >>> MyUSD0.02 >>> >>> On Thursday, October 30, 2014 3:41:45 PM UTC-5, Michael DeHaan wrote: >>>> >>>> Idempotent is one of those frequently misused words. >>>> >>>> Mathematically it basically means F(x) = F(F(x)) for all x. Calling >>>> the same thing twice should return the thing that you got when you called >>>> it the first time. >>>> >>>> For this reason, we don't frequently use this word to describe bugs >>>> about things not doing what you'd suspect, or even if it's just reporting >>>> changes that don't happen. >>>> >>>> As such, I'd rather get down to the root of the problem. >>>> >>>> It seems if you are asking for an EIP and don't specify which one, >>>> you're probably asking for a new one. >>>> >>>> You seem to think that asking for an EIP should not give you a new one, >>>> because the instance already has one. >>>> >>>> This may imply a new mode flag (defaulting to the present behavior) >>>> should possibly exist for the module. What do others think? >>>> >>>> >>>> >>>> On Wed, Oct 29, 2014 at 4:59 PM, erewh0n <[email protected]> wrote: >>>> >>>>> Depending on your use case, ec2_eip is not idempotent. I would like >>>>> to attach a new EIP to an instance *iff* the instance doesn't already >>>>> have >>>>> an EIP attached. >>>>> >>>>> Currently, the module operates in two modes: >>>>> >>>>> 1. if you don't specify an existing EIP address, the module will >>>>> attach a new arbitrary EIP regardless of whether the instance already >>>>> has >>>>> one attached (not idempotent). >>>>> 2. if you do specify an existing EIP address, then the module will >>>>> attach that EIP *iff* the EIP is not attached to any instance. >>>>> >>>>> It seems like case (1) should be idempotent and assume that an >>>>> instance with an already-attached EIP requires no change. >>>>> >>>>> Thoughts? >>>>> >>>>> -- >>>>> 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/15cd891c-5a40-4f1a-996b-4bae04c63c1a%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/ansible-project/15cd891c-5a40-4f1a-996b-4bae04c63c1a%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- 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/70c2efd9-e2fc-4713-9d41-4dcb3c013241%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
