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. Best regards, Fabien On 13/08/2015 11:07, Ricardo Carrillo Cruz wrote: > I lean towards the second option that Jeremy pointed out. > > External users just expect Puppet to bring up services configured by the > module, it makes sense to me having 'running' as default and override that at > the node or wrapper module. > > Regards > > El 13/8/2015 8:30, "Yolanda Robla Mota" <[email protected] > <mailto:[email protected]>> escribió: > > Hi > It's great that you expose that because this review passed through a lot > of eyes and we all +2, we all assumed that the manifest not managing > the zuul services was a bug. > From my perspective, i see advantages on puppet managing these > services, but I can understand that not all end users will want the > same. > Advantages I see for managing services are: > > 1. Manual intervention. If you don't have any extra orchestration > layer on top, such as ansible, you need manual steps to spin up these > services. That can be a blocker for some workflows, such as > automated testing. > > 2. Reliability. It can be better or worse option, but letting puppet > manage the services can be a life-saver if for some reason the > service goes down. For example i've had several problems with zuul-merger > services being down and no one noticing it until reviews started to > fail. Having puppet watching these cannot be the better solution but > it works on the simplest environments. > > So having said that, i think that the parameter option is a good one. > Provide a parameter to zuul, to show if we want it to manage the > services or not, and let end users decide. > > Best > Yolanda > > El 12/08/15 a las 23:15, Jeremy Stanley escribió: > > Change https://review.openstack.org/168306 for puppet-zuul came to > my attention earlier today when it merged. After a quick discussion > on IRC, Spencer proposed a revert which I approved so that we can > get a little more discussion going about this topic. > > First, I'm really sorry I didn't see and weigh in on it sooner (it's > not like I didn't have time, it was ~4.5 months old). Second, we've > grown lots of new core reviewers and I'm thrilled they're reviewing > and approving changes, and I don't want to discourage that in any > way, so thank you to those of you who did review that change. > > In the past, not using ensure=>running on services in our Puppet > modules was intentional, particularly for more stateful services, > especially for services which trigger other (possibly remote) > actions and have a potential to make a mess. It's pretty likely that > those of us who were around for the earlier discussions about it > failed to write it down anywhere obvious, leading others to assume > it's a bug/oversight. I see a couple of obvious solutions though > there are no doubt others: > > 1. Document in each module where we do this, at least in the readme > and probably also in an inline comment around the service > definition, that it's that way on purpose. Optionally, make the > ensure conditional on a class parameter that defaults to unmanaged > in case some downstreams want to use Puppet like a service manager. > > 2. Similar managed/unmanaged parameter, but make it default to > running and override the default to unmanaged in our > ::openstack_project classes. This means that we cease consuming our > modules with the same defaults as downstream users, however if it > turns out that our OpenStack Infra root sysadmins really do have a > very different preference from the majority of our downstream > consumers then at least we can be clear about that. > > > -- > Yolanda Robla Mota > Cloud Automation and Distribution Engineer > +34 605641639 <tel:%2B34%20605641639> > [email protected] <mailto:[email protected]> > > > _______________________________________________ > OpenStack-Infra mailing list > [email protected] > <mailto:[email protected]> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > > > > _______________________________________________ > OpenStack-Infra mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra > _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
