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/6afbec64-dac6-45da-ae86-d40c84141c86%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
