My worry about that sort of approach is it assumes the local playbook directory is authoritative - in our case several people have access to run our playbooks, so that would get messy very quickly.
Keeping state on the managed hosts would be a better idea, and in that case you could keep 'lock files' around in /var that are created at the beginning of a piece of work, and then removed once everything is updated successfully. If those scripts are facts , you can use most of Ansibles existing machinery for free. On 20 December 2016 at 19:20, eric via Ansible Project <[email protected]> wrote: > I'm looking for an enhancement to Ansible that I'm conceiving of as > "persistent variables." Specifically, when one part of my script does > something that registers a variable, I'm typically using that registration > to affect whether or not operations are performed afterwards. However, > scripts can fail, and then I've lost that prior state that something > happened. Running the script again will typically leave the registered > variable in a different state, and the operations that triggered off of the > registered variable may not be performed, even though they should be. > > For a work-around, for example, looking at packages going to be updated on > the system. If the pending package updates include, say, an update to the > database software, then my script pseudo code looks like this: > > # check whether the DB software is going to be updated, record to a file > > # update database > > # check if file exists indicating DB software update - flag DB updated > > # if db updated, run DB migration tool > > # restart database server > > # remove flag file indicating DB software being upgraded > > ----------------------- > Or a similar case: > > # check whether apache web server going to be updated, write a file that > indicates apache update > > # update all packages > > # check whether file exists indicating apache update > > # if apache updated - optionally rewrite Apache config > > # if apache updated - restart apache > > # remove flag file indicating apache update > > ------------------------ > > When I initially wrote my scripts, I recorded the state of whether or not > the DB software or Apache was being updated in a variable. > > However, ansible scripts fail. For example, "update all packages" could > update Apache, but then fail for any number of reasons. So I want to capture > the state of a potential update in a file, so that if Ansible steps fail, > the state that the software has been updated has been captured, so that the > next time the script runs, it still does the right thing and restarts > Apache, for example. I could restart Apache every time, but that is > potentially disruptive to clients, so I don't want to do that except if > required. > > All of which leads me to suggest two enhancements: > > 1) Persisted state variables - as you can see from the scripts above, I have > to write a file saving state (only if update is needed), test that file > later - saved into a variable, and then delete the file that holds the > state. Instead, if I could conditionally "register" a value for a persistent > variable, and then upon successful completion of a script, Ansible itself > cleans up all the persistent variables, then I don't need to have steps for: > writing to a file, checking that file, and removing that file. This will > simplify handling of scenarios where state needs to persist between steps in > an Ansible script. > > 2) Assuming I can get persisted state variables, it would also be useful to > enhance the package management tools (portage, yum, apt, etc...) to record > persistent state about which packages were updated by an update. Only when > the script has run successfully to completion does that variable, and all > the packages updated, actually get removed. Now I can write scripts that > check whether an update has happened in this run of a script, or any > previously unsuccessful run. > > Perhaps there's a better way to accomplish some of the above with existing > Ansible tasks, but I've not found it. > > Eric. > > -- > 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/bd5e22a2-6fb4-4923-ad06-541de3c98a3d%40googlegroups.com. > 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/CAK5eLPRnVYniQQ%2Bpz56kGo40GEhjmucxwxwBGHab5xD%3D79aKxw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
