Anthony,
thank you for your response.

Would you mind addressing the scenarios and implementation options of
installing/updating the system?
I think there is a conflict between the virtue of avoiding state
changes on consecutive runs, and simplicity in implementation.

Thank you for the example of targeting multiple hosts with a single
playbook, with different results for each host.
A playbook that doesn't do state changes scales better when running
against multiple hosts.

On Fri, Jun 18, 2021 at 3:34 PM Antony Stone
<[email protected]> wrote:
>
> On Friday 18 June 2021 at 22:17:30, Jane Prusakova wrote:
>
> > I am new to Ansible, and am trying to understand its best practices.  My
> > team uses Ansible for system setup and product deployment.
> >
> > I am reading that idempotance is the foundational virtue, where playbook
> > idempotence is defined as not doing any state changes on consecutive runs.
> > I am not sure I understand why.
>
> For me, the reason is simple - you want to be able to run ansible multiple
> times on a given machine and be confident that the state it is left in
> afterwards is the same every time.
>
> Suppose you have a machine which does not have a web server installed on it,
> and you have an ansible playbook which installs and configures the web server.
>
> You want to be able to run that playbook once, and end up with a working web
> server.
>
> You want to be able to run that smae playbook again (with no changes) and have
> the same working web server (with no changes) on the target machine.
>
> This is partly because playbooks are often nested, so that you might have one
> for a web server and another for a mail server; you modify the one for the
> mail server but then run both of them; you want the modification you made to
> the mail server playbook to take effect but you want the web server on the
> target machine to stay just the way it was after the first run of the 
> playbook.
>
> > Appreciate any thoughts on why avoiding state changes on consecutive
> > playbook runs is preferred over simplicity and robustness in
> > implementation.
>
> Is that a quote from somewhere?  Is there anywhere in either the ansible
> documentation or any tutorials / online guidelines you have read which say
> that "avoiding state changes on consecutive playbook runs is preferred over
> simplicity and robustness in implementation"?
>
> Idempotence (avoiding state changes on consecutive runs) is essential.
>
> Simplicity, and robustness in implementation, are highly desirable.
>
> Is there a conflict between the two?
>
>
> Antony.
>
> --
> Archaeologists have found a previously-unknown dinosaur which seems to have
> had a very large vocabulary.  They've named it The Saurus.
>
>                                                    Please reply to the list;
>                                                          please *don't* CC me.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/CAGB%3D%3DuLXscYNsgqdYXq389XhjUAB3_vf0ErFfwiUek%3DAqBB_HQ%40mail.gmail.com.

Reply via email to