puppetlabs-puppet_agent
puppetlabs-puppet_agent copied to clipboard
puppetlabs
rework how module manages the service
The module manages the service for some OSs only (and when not PE). This change makes this more consistent to manage the service on all platforms, regardless of PE.
In particular, windows was a case where the module was excluded from managing the service. We want the puppet agent started again even when doing a manual run so that it is restored to service. But there is also the option added to disable this behavior.
Waiting for CLA signature by @rstuart-indue
@rstuart-indue - We require a Contributor License Agreement (CLA) for people who contribute to Puppet, but we have an easy click-through license with instructions, which is available at https://cla.puppet.com/
Note: if your contribution is trivial and you think it may be exempt from the CLA, please post a short reply to this comment with details. http://docs.puppet.com/community/trivial_patch_exemption.html
The windows service is managed differently (and not with puppet) during the upgrade, because the services need to be shut off during upgrade and the upgrade cannot be performed by puppet itself. install_puppet.ps1 includes code that should restore service operation after the upgrade: https://github.com/puppetlabs/puppetlabs-puppet_agent/blob/master/files/install_puppet.ps1#L358
It sounds like you are describing the restart of the application so that it doesn't interfere with installation, but this is different to managing the service. It sounds like there might be two different purposes being talked about here:
- starting the agent after installation or upgrade
- ensuring the service is running all the time
It seems to me that the first is what you are describing as the intent of the code in this module, but the second is what is being done for a large number of systems. If managing the service is not wanted, then I would suggest removing the service resources completely and triggering starts of the agent with whatever tools are necessary but avoiding managing the service. Otherwise, there is going to be conflicts if people choose to manage the service and also use this module on non-PE systems and non-windows systems (eg RHEL).
Another thing to mention here is that the module does not attempt to manage the service on PE at all, even though PE does not manage the puppet service. So, that probably needs to be changed too.
