I’m new to Ansible but have several years of Puppet under my belt so I’m evaluating Ansible to learn if it can resolve some very long term issues I’ve had with Puppet. For example, I’ve created a very simple NTP role like:
John,
This is an issue I have as well. Although it doesn't hurt anything,
it is time consuming and slightly annoying. Perhaps if we could have
some sort of optional handler nullification if a service is started in
the same play?
- James
This isn’t anything wrong with Ansible (or Puppet), because there’s no way for anything to know what’s inside the configuration script.
RPMs can do absolutely anything they want (yes, anything, not just restart services).
My advice is to be ok with it, and go enjoy the 3 seconds to get some coffee or something.
There’s no API to say “this service was recently restarted in the last 3 seconds” and I’m positive you don’t want to implement that anyway.
Does this actually cause a real world problem?
This is an issue I have as well. Although it doesn’t hurt anything,
it is time consuming and slightly annoying.
In my real world needs, it does hurt or would hurt if I am to adopt Ansible. I intend to use Ansible, like I have Puppet, to transform a stateless Linux node into a specific type of appliance upon boot up. It must achieve this on the first run, every time and bouncing a service like this is unsuitable for my needs. (I feel rather alone with these types of problems because most are not using these fabulous tools against stateless systems; you pay once, I pay every time.)
Perhaps if we could have
some sort of optional handler nullification if a service is started in
the same play?
That sounds interesting. It does seem like something that would have to be addressed internally within the service module, at least for a clean solution.
This isn’t anything wrong with Ansible (or Puppet), because there’s no way for anything to know what’s inside the configuration script.
Maybe it’s not wrong, but there should be some way to influence the behavior for cases where it really does matter.
RPMs can do absolutely anything they want (yes, anything, not just restart services).
I’m not worried about the packages bouncing the services. For those that really matter to me, I am the author so I can assure the packages themselves behave as needed.
My advice is to be ok with it, and go enjoy the 3 seconds to get some coffee or something.
There’s no API to say “this service was recently restarted in the last 3 seconds” and I’m positive you don’t want to implement that anyway.
Does this actually cause a real world problem?
Please see my post to James. For me it is a show stopper as it really does cause real world problems that prevent adoption of such tools. I have use cases where we’re talking about way more than 3 seconds … try upwards of a quarter of an hour. I don’t want any magic assumptions about what is considered “recent enough”, but rather enforcement within a single playbook “run”.
How about:
- name: install NTP daemon
yum: name=chrony- name: configure NTP daemon
copy: src=chrony.conf dest=/etc/chrony.conf
notify: restart NTP daemon
register: ntpconfig
- service: name=chronyd enabled=yes state=started
when: not ntpconfig.changed
slight correction, you'd need to split out the service task, first
enabling it, then conditionally starting it
Perfect! Now that’s what I’m talking about. I had this feeling that this had to be possible, but I’m such an Ansible newb to be approaching deeper waters like this, but I also figured if the hard stuff can’t be done, I really don’t care about the simple stuff. I felt this “possibility” because Ansible seems to prefer explicit control whereas puppet aims much more for implicit control.
Thank you so much for such a fast (and elegant) solution. My bug report for same in puppet took over two years to resolved/merged and it still hasn’t made it into a Fedora release yet.
Now I back off to testing for other quirks I’ve had to live with in puppet.
Nope, it’s still completely the same thing as the notify, just made with grosser syntax by not using the notify.
The RPM can still bounce the service.
This is also a non-problem.
Also your explicit/implicit stuff seems like a pretty non-standard comment to me, the resource models are basically the same concept.
BTW, if you ever want to force handlers to run at any point in the file, Ansible can let you.
- meta: flush_handlers
This is way cleaner than the “when” approach above and can be used multiple times.
The problem is the RPM that bounces the service, which has no bearing to Ansible, or any other CM tool.
Nope, it’s still completely the same thing as the notify, just made with grosser syntax by not using the notify.
I don’t follow you here. I left the notify but did add the register and the accompanying when. It can’t be the same thing because it now behaves exactly as I want and w/o these changes it did not.
The RPM can still bounce the service.
As I already stated though, I can assure the RPM will NOT bounce the service. I author the service and RPM and there’s absolutely no such action in the spec file.
Also your explicit/implicit stuff seems like a pretty non-standard comment to me, the resource models are basically the same concept.
Sure, but the execution models are very different. Puppet only started executing (or in their terms “applying the catalog”) in a deterministic fashion fairly recently (around v2.7 IIRC). However, if you change anything, you get a whole new deterministic order of operations that only stays that way until the next change. With Ansible’s top-down execution model, things are much simpler to manage. That’s the explicit/implicit stuff I’m talking about.
BTW, if you ever want to force handlers to run at any point in the file, Ansible can let you.
- meta: flush_handlers
This is way cleaner than the “when” approach above and can be used multiple times.
That too sounds intriguing. Can you please explain how that might be used to achieve my goal here? I don’t understand how this would help.