Open Stack

Fabien Boucher <fboucher at 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