Is your feature request related to a problem?
Yes. When executing a shell script to add/modify a large number of hosts/interfaces, it is possible to have cobblerd restart services such as dhcpd and named so many times in such a short period of time that systemd will mark the services as failed when it hits the start-limit-hit. By default, systemd is configured to trigger this behaviour when 5 restarts occur within 10 seconds. And the result is that the process enters a down state and remains there until a manual reset is done.
The Cobbler CLI used to have a command line flag, --no-sync IIRC, which would tell cobblerd to defer the sync operation until a change is requested without the flag being specified, or a cobbler sync was explicitly requested.
As a developer and administrator
I want to be able to defer managed process synchronization
so that I can use shell scripts to make large batches of changes without having processes like dhcpd or named being locked out of restarting and requiring to be manually reset, or having to add sleeps to the script to slow things down.
Provide a detailed description of the proposed feature
Add a command line option/flag, be it the original one (--no-sync) or an entirely new one, and have the actions (in the CobblerSync class, such as run and run_sync_systems, I believe from a quick search of the code) return without executing the associated sync actions.
Alternatives you've considered
The other options are:
-
Have any batch script do a sleep of several seconds between each cobbler system add or cobbler system edit (or any other command which automatically triggers a sync action). For a script which might be manipulating hundreds of systems, a script which might otherwise run in a handful of minutes could take far longer.
-
Have any script which is run to handle the failure. This could involve either doing multiple recoveries, or accepting downtime for critical network services. While replication of these services is possible (such as by adding a non-authoritative DHCP server, or slave DNS servers), this considerably increases complexity for those services.
Additional information
The --no-sync option was added in commits 67c39163, d254f3bd, changed in commits 2cfbb551, 6d9e11483f, 743b94c7 for an apparent drop in 2.0.?, and cleaned up in commit 287d2313.
Is your feature request related to a problem?
Yes. When executing a shell script to add/modify a large number of hosts/interfaces, it is possible to have
cobblerdrestart services such asdhcpdandnamedso many times in such a short period of time thatsystemdwill mark the services asfailedwhen it hits the start-limit-hit. By default,systemdis configured to trigger this behaviour when 5 restarts occur within 10 seconds. And the result is that the process enters a down state and remains there until a manual reset is done.The Cobbler CLI used to have a command line flag,
--no-syncIIRC, which would tellcobblerdto defer the sync operation until a change is requested without the flag being specified, or acobbler syncwas explicitly requested.As a developer and administrator
I want to be able to defer managed process synchronization
so that I can use shell scripts to make large batches of changes without having processes like
dhcpdornamedbeing locked out of restarting and requiring to be manually reset, or having to add sleeps to the script to slow things down.Provide a detailed description of the proposed feature
Add a command line option/flag, be it the original one (
--no-sync) or an entirely new one, and have the actions (in theCobblerSyncclass, such asrunandrun_sync_systems, I believe from a quick search of the code) return without executing the associated sync actions.Alternatives you've considered
The other options are:
Have any batch script do a sleep of several seconds between each
cobbler system addorcobbler system edit(or any other command which automatically triggers a sync action). For a script which might be manipulating hundreds of systems, a script which might otherwise run in a handful of minutes could take far longer.Have any script which is run to handle the failure. This could involve either doing multiple recoveries, or accepting downtime for critical network services. While replication of these services is possible (such as by adding a non-authoritative DHCP server, or slave DNS servers), this considerably increases complexity for those services.
Additional information
The
--no-syncoption was added in commits 67c39163, d254f3bd, changed in commits 2cfbb551, 6d9e11483f, 743b94c7 for an apparent drop in 2.0.?, and cleaned up in commit 287d2313.