Closed JeffBellegarde closed 10 years ago
I'm usually very cautious with restarting services on configuration changes, which is why I haven't used it in this cookbook, and I'm not looking to add it (at least not by default). What if someone deploys an incorrect configuration and Kafka refuses to start? Or what if Chef runs at approximately the same time on all servers? It can effectively bring down an entire cluster, which I'm pretty sure no-one wants to happen in production.
That being said I'm not against driving this using for example an attribute, where the default behaviour would be to not restart Kafka on configuration changes.
Another solution would be to have another recipe (in this cookbook) that adds the notification part, much like what @dpkp suggests in his comment on #43. This recipe could also potentially add automatic start of Kafka (i.e. add start
to the list of actions for the service
resource).
Not really sure which approach to take with this, what do you guys (@JeffBellegarde, @dpkp) think?
I'm in the restart at the drop of a feather camp. If you want to use an attribute to make it optional, I'm fine with that.
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
When any of the configs change a deferred restart should be sent to the service so it can pick up on the config.
Otherwise, we get a current configuration on disk while the process runs with an out of date config.