<p dir="ltr">Sure. Put it in the agenda perhaps Tuesday morning</p>
<div class="gmail_quote">On 20 Jul 2014 12:11, "Chris Jones" <<a href="mailto:cmsj@tenshu.net">cmsj@tenshu.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi<br>
<br>
I also have some strong concerns about this. Can we get round a table this week and hash it out?<br>
<br>
Cheers,<br>
Chris<br>
<br>
<br>
>> On 20 Jul 2014, at 14:51, Dan Prince <<a href="mailto:dprince@redhat.com">dprince@redhat.com</a>> wrote:<br>
>><br>
>>> On Thu, 2014-07-17 at 15:54 +0100, Michael Kerrin wrote:<br>
>>> On Thursday 26 June 2014 12:20:30 Clint Byrum wrote:<br>
>>><br>
>>> Excerpts from Macdonald-Wallace, Matthew's message of 2014-06-26<br>
>> 04:13:31 -0700:<br>
>><br>
>>>> Hi all,<br>
>><br>
>><br>
>>>> I've been working more and more with TripleO recently and whilst<br>
>> it does<br>
>><br>
>>>> seem to solve a number of problems well, I have found a couple of<br>
>><br>
>>>> idiosyncrasies that I feel would be easy to address.<br>
>><br>
>><br>
>>>> My primary concern lies in the fact that os-refresh-config does<br>
>> not run on<br>
>><br>
>>>> every boot/reboot of a system. Surely a reboot *is* a<br>
>> configuration<br>
>><br>
>>>> change and therefore we should ensure that the box has come up in<br>
>> the<br>
>><br>
>>>> expected state with the correct config?<br>
>><br>
>><br>
>>>> This is easily fixed through the addition of an "@reboot" entry in<br>
>><br>
>>>> /etc/crontab to run o-r-c or (less easily) by re-designing o-r-c<br>
>> to run<br>
>><br>
>>>> as a service.<br>
>><br>
>><br>
>>>> My secondary concern is that through not running os-refresh-config<br>
>> on a<br>
>><br>
>>>> regular basis by default (i.e. every 15 minutes or something in<br>
>> the same<br>
>><br>
>>>> style as chef/cfengine/puppet), we leave ourselves exposed to<br>
>> someone<br>
>><br>
>>>> trying to make a "quick fix" to a production node and taking that<br>
>> node<br>
>><br>
>>>> offline the next time it reboots because the config was still left<br>
>> as<br>
>><br>
>>>> broken owing to a lack of updates to HEAT (I'm thinking a "quick<br>
>> change"<br>
>><br>
>>>> to allow root access via SSH during a major incident that is then<br>
>> left<br>
>><br>
>>>> unchanged for months because no-one updated HEAT).<br>
>><br>
>><br>
>>>> There are a number of options to fix this including Modifying<br>
>><br>
>>>> os-collect-config to auto-run os-refresh-config on a regular basis<br>
>> or<br>
>><br>
>>>> setting os-refresh-config to be its own service running via<br>
>> upstart or<br>
>><br>
>>>> similar that triggers every 15 minutes<br>
>><br>
>><br>
>>>> I'm sure there are other solutions to these problems, however I<br>
>> know from<br>
>><br>
>>>> experience that claiming this is solved through "education of<br>
>> users" or<br>
>><br>
>>>> (more severely!) via HR is not a sensible approach to take as by<br>
>> the time<br>
>><br>
>>>> you realise that your configuration has been changed for the last<br>
>> 24<br>
>><br>
>>>> hours it's often too late!<br>
>><br>
>>> So I see two problems highlighted above.<br>
>><br>
>><br>
>>> 1) We don't re-assert ephemeral state set by o-r-c scripts. You're<br>
>> right,<br>
>><br>
>>> and we've been talking about it for a while. The right thing to do<br>
>> is<br>
>><br>
>>> have os-collect-config re-run its command on boot. I don't think a<br>
>> cron<br>
>><br>
>>> job is the right way to go, we should just have a file in /var/run<br>
>> that<br>
>><br>
>>> is placed there only on a successful run of the command. If that<br>
>> file<br>
>><br>
>>> does not exist, then we run the command.<br>
>><br>
>><br>
>>> I've just opened this bug in response:<br>
>><br>
>><br>
>>> <a href="https://bugs.launchpad.net/os-collect-config/+bug/1334804" target="_blank">https://bugs.launchpad.net/os-collect-config/+bug/1334804</a><br>
>><br>
>><br>
>><br>
>><br>
>> I have been looking into bug #1334804 and I have a review up to<br>
>> resolve it. I want to highlight something.<br>
>><br>
>><br>
>><br>
>> Currently on a reboot we start all services via upstart (on debian<br>
>> anyways) and there have been quite a lot of issues around this -<br>
>> missing upstart scripts and timing issues. I don't know the issues on<br>
>> fedora.<br>
>><br>
>><br>
>><br>
>> So with a fix to #1334804, on a reboot upstart will start all the<br>
>> services first (with potentially out-of-date configuration), then<br>
>> o-c-c will start o-r-c and will now configure all services and restart<br>
>> them or start them if upstart isn't configured properly.<br>
>><br>
>><br>
>><br>
>> I would like to turn off all boot scripts for services we configure<br>
>> and leave all this to o-r-c. I think this will simplify things and put<br>
>> us in control of starting services. I believe that it will also narrow<br>
>> the gap between fedora and debian or debian and debian so what works<br>
>> on one should work on the other and make it easier for developers.<br>
><br>
> I'm not sold on this approach. At the very least I think we want to make<br>
> this optional because not all deployments may want to have o-r-c be the<br>
> central service starting agent. So I'm opposed to this being our (only!)<br>
> default...<br>
><br>
> The job of o-r-c in this regard is to assert state... which to me means<br>
> making sure that a service is configured correctly (config files, set to<br>
> start on boot, and initially started). Requiring o-r-c to be the service<br>
> starting agent (always) is beyond the scope of the o-r-c tool.<br>
><br>
> If people want to use it in that mode I think having an *option* to do<br>
> this is fine. I don't think it should be required though. Furthermore I<br>
> don't think we should get into the habit of writing our elements in such<br>
> a matter that things no longer start on boot without o-r-c in the mix.<br>
><br>
> I do think we can solve these problems. But taking a hardwired<br>
> prescriptive approach is not good here...<br>
><br>
>><br>
>><br>
>><br>
>> Having the ability to service nova-api stop|start|restart is very<br>
>> handy but this will be a manually thing and I intend to leave that<br>
>> there.<br>
>><br>
>><br>
>><br>
>> What do people think and how best do I push this forward. I feel that<br>
>> this leads into the the re-assert-system-state spec but mainly I think<br>
>> this is a bug and doesn't require a spec.<br>
>><br>
>><br>
>><br>
>> I will be at the tripleo mid-cycle meetup next and willing to discuss<br>
>> this with anyone interested in this and put together the necessary<br>
>> bits to make this happen.<br>
>><br>
>><br>
>><br>
>> Michael<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>