It's a tricky one - you probably don't want production bouncing
services all day long
but on the other hand I doubt you never want to pick up any config
changes either.
One day you'll have a power outage or something and that's a bad time
to find out your
configuration file is actually invalid.
That said, we do occasionally do this against prod. if we've tested in
other envs and really
do need to avoid a restart.
( A good example would be something we can dynamically add to a
service configuration by
hand at runtime without a restart, but we also want to ensure the
on-disk config is up to date).
If we don't want a service to bounce we
* do a 'dummy run' of ansible (-C) with the -D (diff) option
* see what Ansible would change
* make those changes by hand
that way the handlers don't fire, since Ansible didn't change the
files contents.
This is a hassle, but since we don't want to encourage this behaviour
that's fine :)
> --
> 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
ansible-proje...@googlegroups.com.
> To post to this group, send email to
ansible...@googlegroups.com.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/ansible-project/93b8dbaf-0c77-456b-9b96-37f99a1caf1b%40googlegroups.com.
> For more options, visit
https://groups.google.com/d/optout.