Open Stack

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" <yolanda.robla-mota at hp.com <mailto:yolanda.robla-mota at hp.com>> 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>
>     yolanda.robla-mota at hp.com <mailto:yolanda.robla-mota at hp.com>
> 
> 
>     _______________________________________________
>     OpenStack-Infra mailing list
>     OpenStack-Infra at lists.openstack.org <mailto:OpenStack-Infra at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> 
> 
> 
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>