Right it is becoming clearer where you are going with this.  Ansible has a
few modes to do a job run. If you want to see what is going to be applied
you can use check mode. If you want to apply at a more convenient time then
use run (which is the default)

On Sat, 19 Jun 2021 at 10:01 AM jane p <[email protected]> wrote:

> On Fri, Jun 18, 2021 at 4:26 PM Antony Stone
> <[email protected]> wrote:
> >
> > On Friday 18 June 2021 at 23:10:46, jane p wrote:
> >
>
> > If you install a second time (with the same playbook) you want no further
> > changes to be made, because what needed to be installed has already been
> > instealled.
> >
> > If you update, you want the system to be updated (again, pretty obvious).
> >
>
> It is not trivial to distinguish between 'install a second time' and
> 'update'.
> When the playbook starts, it is not known whether there are any
> changes, and which specific changes have been made.
>
> > If you update a second time (with the same playbook) you want no further
> > changes to be made, because the system has already been updated, nothing
> > further needs updating; the system should be left as it is.
> >
>
> Installing for the first time and updating-in-place may not be identical.
> Consider a system that involves a web server.  On initial install the
> server is started at the end, after all the apps are installed.
> On subsequent update the server is already running.  Should the web
> server be reloaded?  If apps are updated, then yes, if not, then not
> necessarily.
>
> Encoding the dependency for each app update to web server reload is
> complexity of the system expressed in Ansible.
> Not encoding the dependency for each update, and reloading the web
> server in all cases is breaking the 'no state changes if nothing got
> updated' requirement at least some of the time.
>
> > What you would like to see, or what example can you give, as a "simple
> > implementation" which does not leave the target system in the same state
> after
> > every run?
> >
> I think leaving the target system in the same state after every run is
> essential.
> The question is about whether state changes within the run are allowed.
>
> >
> > Antony.
> >
> > --
> > "Have you been drinking brake fluid again?  I think you're addicted to
> the
> > stuff."
> >
> > "No, no, it's alright - I can stop any time I want to."
> >
> >                                                    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%3DuKFWXoZXnDsGB5Qqc7%2BOhvacxHqjpz_68x83BqQJuVkxA%40mail.gmail.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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/CA%2BjXPxh1GNNNsVCA-4HosGpsQUXaPvMTOj%2BJf1cOCS5Wr_A_ZQ%40mail.gmail.com.

Reply via email to