Bug 1435972 - [RFE] - Option to disable autostart for puppet agent
Summary: [RFE] - Option to disable autostart for puppet agent
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Bootstrap
Version: 6.2.8
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: Unspecified
Assignee: Rich Jerrido
QA Contact: Daniel Lobato Garcia
URL:
Whiteboard:
Depends On:
Blocks: 1122832
TreeView+ depends on / blocked
 
Reported: 2017-03-26 11:04 UTC by Simon Reber
Modified: 2019-04-01 20:27 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-02-21 12:39:11 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github Katello katello-client-bootstrap issues 173 0 None closed [RFE] Allow user to set 'noop=true' in the puppet.conf file. 2020-03-31 10:01:56 UTC
Github Katello katello-client-bootstrap issues 174 0 None closed [RFE] - Allow user to disable autostart of Puppet Agent 2020-03-31 10:01:49 UTC
Red Hat Product Errata RHSA-2018:0336 0 normal SHIPPED_LIVE Important: Satellite 6.3 security, bug fix, and enhancement update 2018-02-21 22:43:42 UTC

Comment 1 Rich Jerrido 2017-03-27 12:53:48 UTC
Based upon this comment

"When migrating systems from Satellite 5 to Satellite 6 it's possible that these systems the first time run `puppet`. To minimize impact, it would be nice, if only `puppet` with `noop` is running and `puppet` remains stopped.
This would allow an engineering to check if puppet is working correctly and not modifying something mission critical. It would then also allow him to control the next `puppet` run and therefore avoid any sort of issue because of missing or faulty modules."

I think there are two possible ways to solve this

- Leave the current code which leaves the puppet agent enabled and started, but put 'noop=true' in the puppet.conf when asked. The admin can then remove this later with 'puppet config set --section agent noop false'
- Add a new --skip option to allow the user to pass '--skip autostart-puppet' (for example, we might name it something else). which, when asked, will skip the chkconfig puppet on & service puppet start portions of the script. 

Which do you prefer? The former allows the admin to continue making changes to the puppet configuration whilst still maintaining insight into the possible changes. Plus it protects you if a (possibly different) admin mistakenly starts the daemon

Comment 2 Simon Reber 2017-03-27 13:00:54 UTC
(In reply to Rich Jerrido from comment #1)
> Based upon this comment
> 
> "When migrating systems from Satellite 5 to Satellite 6 it's possible that
> these systems the first time run `puppet`. To minimize impact, it would be
> nice, if only `puppet` with `noop` is running and `puppet` remains stopped.
> This would allow an engineering to check if puppet is working correctly and
> not modifying something mission critical. It would then also allow him to
> control the next `puppet` run and therefore avoid any sort of issue because
> of missing or faulty modules."
> 
> I think there are two possible ways to solve this
> 
> - Leave the current code which leaves the puppet agent enabled and started,
> but put 'noop=true' in the puppet.conf when asked. The admin can then remove
> this later with 'puppet config set --section agent noop false'
Let's go with this option. I think it's best and as you said will prevent bad things from happening if somebody by mistake starts the puppet again anyway.

Comment 3 Evgeni Golov 2017-03-28 07:14:19 UTC
I must admit I prefer the --skip solution, as that is exactly why I rewrote the old --skip-<foo> logic to be more generic: allow us to skip basically every single step in the chain, so in this case "--skip puppet-enable" or similar with skipping the "chkconfig puppet on" and "service puppet restart" ones.

That said there is nothing that prevents us to implement both, or only the "noop = true" option.

If doing the noop=true way, one could think we might want to make random options in puppet.conf editable. But then again we probably don't want to integrate a "config management" into bootstrap (besides me joking when bootstrap will have more options than Ansible...)

Comment 4 Simon Reber 2017-03-28 07:22:30 UTC
(In reply to Evgeni Golov from comment #3)
> I must admit I prefer the --skip solution, as that is exactly why I rewrote
> the old --skip-<foo> logic to be more generic: allow us to skip basically
> every single step in the chain, so in this case "--skip puppet-enable" or
> similar with skipping the "chkconfig puppet on" and "service puppet restart"
> ones.
Certainly a nice feature and also a possibility. As mentioned, the nice thing about changing the `puppet` configuration is that we can overcome human mistake if somebody enables or runs `puppet` on this host.

> That said there is nothing that prevents us to implement both, or only the
> "noop = true" option.
> 
> If doing the noop=true way, one could think we might want to make random
> options in puppet.conf editable. But then again we probably don't want to
> integrate a "config management" into bootstrap (besides me joking when
> bootstrap will have more options than Ansible...)
Thinking a bit, it could make sense for this request to actually implement both. There may be cases where enabling/restarting puppet may simply be skipped (for whatever reason). But there may also be cases where the customer intentionally only want to run `puppet` with `noop` and it therefore might be appreciated if that can be set within the script without requiring much effort.

Comment 5 Simon Reber 2017-03-28 07:25:47 UTC
Original request for this RFE


3. What is the nature and description of the request?

When migrating systems from Satellite 5 to Satellite 6 it's possible that these systems the first time run `puppet`. To minimize impact, it would be nice, if only `puppet` with `noop` is running and `puppet` remains stopped.
This would allow an engineer to check if puppet is working correctly and not modifying something mission critical. It would then also allow him to control the next `puppet` run and therefore avoid any sort of issue because of missing or faulty modules.

4. Why does the customer need this? (List the business requirements here)

Customer is migrating from Satellite 5 to Satellite 6. With Satellite 5 the customer does not yet use `puppet` but has created various modules now with Satellite 6. In order to avoid production impact, the customer would like to run only `puppet` with `noop` when running the `bootstrap` script.
Then check the logs and see if it breaks something or not. If all is good he will manually or automated run a `puppet` and only then enable `puppet`
 
5. How would the customer like to achieve this? (List the functional requirements here)

Provide additional option in the `bootstrap` script to have the ability and disable the autostart of `puppet` agent

6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.

Run the `bootstrap` script with the option that does disable the autostart of `puppet` and check on whether `noop` `puppet` is run and the agent remains disable or if it still is started

Comment 7 pm-sat@redhat.com 2017-06-01 20:35:32 UTC
11405401

Comment 8 Daniel Lobato Garcia 2017-08-23 14:33:59 UTC
Verified.

Tested with Satellite 6.3 Snap 12.

Downloaded pub/bootstrap.py, then verified that --help shows a '--skip' option with 'enable-puppet'. If this argument is passed, EL6 and EL7 hosts don't autostart puppet.

Comment 11 errata-xmlrpc 2018-02-21 12:39:11 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:0336


Note You need to log in before you can comment on or make changes to this bug.