Fabien Boucher <fbouc...@redhat.com> writes: > Hi, > > I apologize I wasn't here yesterday to discuss about that on IRC. > I was surprised also about not letting puppet ensuring that the service is > running and > now I understand well the reason behind it. But I think too, that for > most of downstream users (like those of puppet-openstackci) the most obvious > behavior > is running by default. Having a switch to disable the default and disabling > it in > system-config seems fine. > > Furthermore an explanation as a comment about why we deactivate it from > system-config is good to have.
That's okay, we're trying to have this conversation on the mailing list to make sure it's widely seen and participated in. We're not doing a great job of that, but we'll keep trying. :) Anyway, I think Jeremy described the history and our thinking well. My preference would be to generally "enable=>true" but not "ensure=>running". For some of our services, having them start before a sysadmin has verified the state of the system can be dangerous (think Gerrit publishing a malformed git repo to github). Moreover, sometimes we need to stop those services for a brief time to fix something, and having puppet automatically restart them could be dangerous. We could stop puppet, and sometimes we do, but that is an extra thing someone needs to remember to do. But more importantly, sometimes we stop a service, then run puppet to apply a configuration change, then start it again after verification or further work. That is impossible to do if puppet sets "ensure=>running". Put another way, I believe our overall strategy is to use puppet as a configuration management system, but not an orchestration system. We're moving towards using ansible as the orchestration system. It turns out that generally the desire to have "ensure=>running" set mostly comes from wanting a newly launched server to have its services running. The orchestration system that launched the server is uniquely situated to understand that it is running the bring-up of the server, and whether any external dependencies are prepared for the server start. So if we want to automate that, I believe that is the place to do it. -Jim _______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
