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
(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.
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...)
(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.
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
Moving to POST as both of the following commits are merged upstream - https://github.com/Katello/katello-client-bootstrap/commit/e096a7d066edb845e88ed0e34a0fd1671b2e8913 - https://github.com/Katello/katello-client-bootstrap/commit/69e22fefb91ceb57c7b15a83b3faac5c70e8e251
11405401
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.
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