Closed espenfl closed 4 years ago
e.g. set cache_valid_time: 3600 for 1h
Not sure why that was marked as resolved. Should we not just update the cache on every trigger of ansible
? I find that maybe the safest. Maybe not?
I'm surprised this does not trigger the idempotency check, since the default value is zero Maybe it checks the result and would fail only if there actually were some updates?
Yes I suspect so, but have not actually checked.
Thanks for your work @espenfl - let me know once you think it's ready to be merged. I see no barriers to merging this.
Happy to help. Let us merge.
What did I say about the apt_cache ;-) https://travis-ci.org/marvel-nccr/ansible-role-aiida/jobs/641438706#L758
Anyhow, I'll fix this as well as the rest extra
Great. Did not consider that ;) In fact this is an example of tweaking to pass a test which yields a behavior you not necessarily want in actual use (in case apt have some updates put in during the time slot that is). Of course the benefits as a whole of idempotence outweights this I guess. Thanks for fixing the remaining bits.
In fact this is an example of tweaking to pass a test which yields a behavior you not necessarily want in actual use (in case apt have some updates put in during the time slot that is).
I'm not sure that is true. Note that even if new versions of a package appear in between ansible runs, our role will actually not update them (default of apt:
is state:present
, not state:latest
).
If I understand the ansible philosophy correctly, then in the "strict interpretation" apt-get update
should actually be executed only once and never again.
The way to handle apt package updates via ansible is through setting up an automatic cron job (we do this on Materials Cloud servers for security updates) - it's not the job of the provisioner.
Of course, when you change the role and require a different minimal version of a package, then this should result in a changed state.
Good points.
fixes #14 fixes #16
Added support and tests on RHEL systems