Open ArieHein opened 8 years ago
I did say in the use cases (bottom of the page, that it was a bad example ;) ). The point was more to give possible implementation based on an LCM extension.
Also, for DSC, I'm all for immutability anyway. Truth is, it's probably something you can't achieve at 100% unless you're dealing only with containers. What you aim is for an end state, and life will happen and you'll need a reboot because of a config drift (wanted or not, mistake or not), but it might be worse rebooting during certain time, than letting it misconfigured.
Last point, I'm not up for managing a configuration workflows, besides the bare minimum, and I classify Maintenance window as part of the minimum. There's already many ways to do it, but because they're not native to the LCM, it's painful (and that's mainly why the example I gave is not good).
Though I understand the need: no one wants a production server restarted in the middle of the day. But I think its not the right way.
Though you can use DSC for just one server (bit overkill), if the intention of the Sysadmin\IT\OPs to push a new configuration to the server in the middle of the day, its probably something he\she needed asap and was approved ? Otherwise it was a "mistake" on their part ?
If he had used a different tool for configuration or went on and manually restarted the server, that's a choice. So while I accept people setting the RequiresReboot = $true on prod servers, its still a choice. I would go with $True as I'm concise enough to understand the meaning of any configuration change being delivered to the node. Why would I push a configuration change to be "hanging in" just so it will come into effect 10 hours later when the server is restarted ? how does that contribute to the "State" part of DSC and knowing for 100 at what state your machine is at any given time ?
Adding a maintenance window will make it too complex and turn it into a Workflow based decision and not configuration proper. Setting it to $false and using an external scheduling system to push the new Configuration AND do the restart based on that systems understanding of maintenance window is preferred, at least by me :)