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] > <javascript:>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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/b95da511-356b-4b3d-bb28-b1ac7e578c9a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
