Open Stack

Thank you Jeremy for noticing what went wrong and acting quickly to repair
it, and for starting this thread.

I think calls to increase documentation are fine... writing and approving
the same change to 60+ modules is getting rather tired though. Maybe one
file in system-config or openstackci with some general guidelines on
modules and their behaviour?

As for exposing the functionality Paul's example snippet isn't exactly what
we should do. In that case ensure is set to either running or stopped. We
want to let the service state float and have puppet be uninvolved. I think
we should have each of our classes take a $service_ensure parameter (which
defaults to undef) then all service resources take a ensure =>
$service_ensure. Passing undef in like this will have the behaviour of not
managing the service.

While we have service unmanagement in place for some services, other
services are ensure => running (all apache service stanzas for instance),
We should probably determine some criteria for what is 'touchy' enough to
be unmanaged. Jeremy had some thoughts on this I believe.

As an aside, it was mentioned that if you have puppet ensuring resources,
you then cannot make changes to config files without affecting services.
You can run puppet agent and apply with a --tags parameter. This causes
only resources matching your tag to be created. This allows you to use
puppet to manage files without managing other resources:

[ruby-1.9.3-p551]$: cat tags.pp


file { '/tmp/foo':
  ensure => file,
}

notify { 'derp':
}

[ruby-1.9.3-p551]$: puppet apply --tags file tags.pp
Notice: Compiled catalog for hertz.nibalizer.com in environment production
in 0.06 seconds
Notice: /Stage[main]/Main/File[/tmp/foo]/ensure: created
Notice: Finished catalog run in 0.04 seconds




On Thu, Aug 13, 2015 at 1:32 PM, Yolanda Robla Mota <
yolanda.robla-mota at hp.com> wrote:

> Ok, but i continue seeing ths problem again between what infra says it's
> reasonable,
> and i fully believe your are right, and what downstream users are
> expecting on that.
>
> So why be opinionated on it? My opinion is to add the possibility to the
> module,
> defaulting to false so when an user enables it, it's fully aware about
> what he is doing
> and the consequences it may have.
>
> El 13/08/15 a las 18:23, James E. Blair escribió:
>
> 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
>>
>> _______________________________________________
>> OpenStack-Infra mailing list
>> OpenStack-Infra at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>
>
> --
> Yolanda Robla Mota
> Cloud Automation and Distribution Engineer
> +34 605641639
> yolanda.robla-mota at hp.com
>
>
>
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>



-- 
Spencer Krum
(619)-980-7820
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20150814/0dcbf67d/attachment-0001.html>