<div dir="ltr">Andrew, we have extended system tests passing with our current pacemaker corosync code. Either it is your environment or some bug we cannot reproduce. Also, it may be related to puppet ordering issues thus trying to start some services before some others. As [2] is the only issue you are pointing at now, let's create a bug and track it in Launchpad.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 17, 2014 at 11:20 AM, Andrew Woodward <span dir="ltr"><<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[2] still has no positive progress, simply making puppet stop the<br>
services isn't all that usefull, will need to move towards always<br>
using over-ride files<br>
[3] is closed as it hasn't occurred in two days<br>
[4] may be closed as its not occuring in CI or on my testing anymore<br>
<br>
[5] is closed, was due to [7]<br>
<br>
[7] <a href="https://bugs.launchpad.net/puppet-neutron/+bug/1343009" target="_blank">https://bugs.launchpad.net/puppet-neutron/+bug/1343009</a><br>
<br>
CI is passing CentOS now, and only failing ubuntu in OSTF. This<br>
appears to be due services not being properly managed in<br>
corosync/pacemaker<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Jul 15, 2014 at 11:24 PM, Andrew Woodward <<a href="mailto:xarses@gmail.com">xarses@gmail.com</a>> wrote:<br>
> [2] appears to be made worse, if not caused by neutron services<br>
> autostarting with debian, no patch yet, need to add mechanism to ha<br>
> layer to generate override files.<br>
> [3] appears to have stopped with this mornings master<br>
> [4] deleting the cluster, and restarting mostly removed this, was<br>
> getting issue with $::osnailyfacter::swift_partition/.. not existing<br>
> (/var/lib/glance), but is fixed in rev 29<br>
><br>
> [5] is still the critical issue blocking progress, I'm super at a loss<br>
> of why this is occuring. Changes to ordering have no affect. Next<br>
> steps probably involve pre-hacking keystone and neutron and<br>
> nova-client to be more verbose about it's key usage. As a hack we<br>
> could simply restart neutron-server but I'm not convinced the issue<br>
> can't come back since we don't know how it started.<br>
><br>
><br>
><br>
> On Tue, Jul 15, 2014 at 6:34 AM, Sergey Vasilenko<br>
> <<a href="mailto:svasilenko@mirantis.com">svasilenko@mirantis.com</a>> wrote:<br>
>> [1] fixed in <a href="https://review.openstack.org/#/c/107046/" target="_blank">https://review.openstack.org/#/c/107046/</a><br>
>> Thanks for report a bug.<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>
> --<br>
> Andrew<br>
> Mirantis<br>
> Ceph community<br>
<br>
<br>
<br>
--<br>
Andrew<br>
Mirantis<br>
Ceph community<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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>Skype kuklinvv<br>
45bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div>

</div>