<div dir="ltr"><div><div>Andrew,<br><br></div></div>[2] may be due to agents failing to start. Incorrect agents configuration will lead to agents unability to start and pacemaker timeouts. [3] I do not see failures in rabbit service as I see that it succesfully transitioned from stopped to running state. [4] Swift error shows that you have incorrect rings configuration. <br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 15, 2014 at 9:23 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">Friday, resolved the haproxy / vip issue. It was due to loosing<br>
net.ipv4.ip_forward [1] and then we regressed back to not working at<br>
all in HA or Simple. There was also an issue with the neutron keystone<br>
call being cached oddly causing a trace. Removing the ability to cache<br>
the object appears to have stopped the error, but the changes leading<br>
into learning about this issue may have steered us into this not<br>
working again.<br>
<br>
Today, fought on the regression<br>
<br>
HA deployment testing is completely blocked by [2], [3]. Usually this<br>
occurs after puppet re-runs the controller after an error. This<br>
frequently occurs due to swift [4].<br>
<br>
Simple deployment testing is plagued by neutron notifiers auth failures [5].<br>
<br>
There is some minor annoyance with [6] that doesn't have to be fixed,<br>
but is annoying. There is another variant where other, non-recoverable<br>
(usually malformed-syntax errors) are also caught in the retry when<br>
they should be outright aborted on. This is likely due to the regex in<br>
neutron.rb being overly grabby.<br>
<br>
[1] <a href="https://bugs.launchpad.net/fuel/+bug/1340968" target="_blank">https://bugs.launchpad.net/fuel/+bug/1340968</a><br>
[2] <a href="https://gist.github.com/xarses/219be742ab04faeb7f53#file-pacemaker-corosync-error" target="_blank">https://gist.github.com/xarses/219be742ab04faeb7f53#file-pacemaker-corosync-error</a><br>
[3] <a href="https://gist.github.com/xarses/219be742ab04faeb7f53#file-rabbit-service-failure" target="_blank">https://gist.github.com/xarses/219be742ab04faeb7f53#file-rabbit-service-failure</a><br>
[4] <a href="https://gist.github.com/xarses/219be742ab04faeb7f53#file-swift-error" target="_blank">https://gist.github.com/xarses/219be742ab04faeb7f53#file-swift-error</a><br>
[5] <a href="https://gist.github.com/xarses/219be742ab04faeb7f53#file-neutron-vif-plug-error" target="_blank">https://gist.github.com/xarses/219be742ab04faeb7f53#file-neutron-vif-plug-error</a><br>
[6] <a href="https://gist.github.com/xarses/219be742ab04faeb7f53#file-neutron_network-changes-shared-on-existing-network" target="_blank">https://gist.github.com/xarses/219be742ab04faeb7f53#file-neutron_network-changes-shared-on-existing-network</a><br>

<div class="HOEnZb"><div class="h5"><br>
On Fri, Jul 11, 2014 at 12:08 AM, Andrew Woodward <<a href="mailto:xarses@gmail.com">xarses@gmail.com</a>> wrote:<br>
> Retested today<br>
> ubuntu single nova vlan - works<br>
> centos single nova dhcp - works<br>
> ubuntu single neutron gre - works<br>
> centos single neutron vlan - works<br>
> centos ha(1) neutron vlan - fail haproxy issue<br>
> ubuntu ha(1) neutron gre - fail haproxy issue.<br>
><br>
> haproxy / vip issue:<br>
><br>
> due to whatever reason that I haven't been able to track down yet, the ip<br>
> netns namespaces (public and management) ns_IPaddr2 vips can not ping or<br>
> otherwise communicate with nodes remote to who ever owns the respective vip.<br>
> Once this issue is resolved, I believe that CI should pass given that the<br>
> build appears 100% functional except that computes cant connect to the vip<br>
> properly.<br>
><br>
><br>
> On Thu, Jul 10, 2014 at 1:05 AM, Mike Scherbakov <<a href="mailto:mscherbakov@mirantis.com">mscherbakov@mirantis.com</a>><br>
> wrote:<br>
>><br>
>> We had a call between Andrew (@xarses), Vladimir Kuklin (@aglarendil) and<br>
>> myself (@mihgen) today to finally sort out Neutron ML2 integration in Fuel.<br>
>> We didn't have @xenolog on the call, but hopefully he is more or less fine<br>
>> with all below, and kindly request him to confirm :)<br>
>> Discussed following topics, with an agreement from all participants:<br>
>><br>
>> Risks of merging <a href="https://review.openstack.org/#/c/103280" target="_blank">https://review.openstack.org/#/c/103280</a> (@xarses,<br>
>> upstream puppet module, will further refer as "280") vs<br>
>> <a href="https://review.openstack.org/#/c/103947" target="_blank">https://review.openstack.org/#/c/103947</a> (@xenolog, extending existing puppet<br>
>> module with ML2 support, will further refer as "947")<br>
>><br>
>> We all agree, that 280 is strategically the way to go. It was so by<br>
>> design, and 947 was done only as risk mitigation plan in case if 280 is not<br>
>> ready in time<br>
>> Both 280 and 947 were manually verified in combinations of<br>
>> ubuntu/centos/vlan/gre/ha, 280 needs to be verified with nova-network<br>
>> 947 was ready a week ago and considered to be more stable solution<br>
>> 280 is has much higher risks to introduce regressions, as it is basically<br>
>> rearchitecturing of Neutron puppet module in Fuel<br>
>> 947 has backward compatibility support with legacy OVS, while 280 doesn't<br>
>> have it at the moment<br>
>><br>
>> Mellanox & VMWare NSX dependency on ML2 implementation rebase time<br>
>><br>
>> Rebase itself should not be hard<br>
>> It has to be tested and may take up to next WE to do all<br>
>> rebases/testing/fixing<br>
>> As both Mellanox & NSX Neutron pieces are isolated, it can be an exception<br>
>> for merging by next TH<br>
>><br>
>> Discussed sanitize_network_config [1]<br>
>><br>
>> @aglarendil points out that we need to verify input params which puppet<br>
>> receives in advance, before waiting hours of deploy<br>
>> @mihgen's point of view is that we need to consider each Fuel component as<br>
>> module, and verify output of it with certain input params. So there is no<br>
>> point to verify input in puppet, if it's being verified in output of<br>
>> Nailgun.<br>
>> @xarses says that we need to verify configuration files created in system<br>
>> after module execution, to check if it matches with module input params<br>
>> Overall topic has been discussed much more extensively, and it needs<br>
>> further follow up. @aglarendil confirms that it is Ok to remove sanitize for<br>
>> now, but start writing much more tests to check that 280 deploys correctly<br>
>> right away<br>
>><br>
>> Action plan we've come up with:<br>
>><br>
>> Merge 947, as less risky at the moment, also considering the fact that 280<br>
>> doesn't pass CI<br>
>><br>
>> this will immediately unblock Mellanox & NSX teams so they can rebase on<br>
>> ML2 implementation<br>
>><br>
>> In parallel, create a test plan for 280 together with QA team<br>
>> @xenolog to join 280's effort, start fixing issues discovered there,<br>
>> including [2]<br>
>> Build an ISO, based on 280, and start testing it according to the plan<br>
>> Merge 280 once test plan is executed and issues fixed. Expected on Monday.<br>
>><br>
>> [1] <a href="https://review.openstack.org/#/c/99807/1/specs/5.1/ml2-neutron.rst" target="_blank">https://review.openstack.org/#/c/99807/1/specs/5.1/ml2-neutron.rst</a><br>
>> [2]<br>
>> <a href="https://fuel-jenkins.mirantis.com/job/master_fuellib_review_systest_ubuntu/1608/" target="_blank">https://fuel-jenkins.mirantis.com/job/master_fuellib_review_systest_ubuntu/1608/</a><br>
>><br>
>> Thanks,<br>
>><br>
>><br>
>> On Wed, Jul 9, 2014 at 10:31 PM, Andrew Woodward <<a href="mailto:xarses@gmail.com">xarses@gmail.com</a>> wrote:<br>
>>>><br>
>>>> Teams from MElanox and VMware based their work on current implementation<br>
>>>> of Neutron<br>
>>><br>
>>> Mlnx appears to not set any neutron settings, so wont be enabled<br>
>>> correctly with out some more TLC<br>
>>> (<br>
>>> <a href="https://wiki.openstack.org/wiki/Mellanox-Neutron-Icehouse-Redhat#Neutron_Server_Node" target="_blank">https://wiki.openstack.org/wiki/Mellanox-Neutron-Icehouse-Redhat#Neutron_Server_Node</a><br>
>>> )<br>
>>><br>
>>> NSX appears to be using legacy OVS, but assumes just whatever the default<br>
>>> core_plugin is so it will need some TLC too.<br>
>>><br>
>>>> to merge <a href="https://review.openstack.org/#/c/103280" target="_blank">https://review.openstack.org/#/c/103280</a> in fuel-5.1<br>
>>><br>
>>> Link is wrong should be <a href="https://review.openstack.org/#/c/103947" target="_blank">https://review.openstack.org/#/c/103947</a><br>
>>><br>
>>>><br>
>>>> To base Neutron implementation for 6.0 get<br>
>>>> <a href="https://review.openstack.org/#/c/103280/" target="_blank">https://review.openstack.org/#/c/103280/</a> and start working for adapt this<br>
>>>> for Juno Neutron.<br>
>>><br>
>>> I still think we should merge it<br>
>>>><br>
>>>> Also we should discuss how to make HA-wrapper more pluggable.<br>
>>><br>
>>> <a href="https://review.openstack.org/#/c/103279/" target="_blank">https://review.openstack.org/#/c/103279/</a> makes it very pluggable, and<br>
>>> felt like the best start, what else do we need to add in the near term?<br>
>>> Should we just extend it as we move more components to it?<br>
>>><br>
>>><br>
>>> On Wed, Jul 9, 2014 at 9:21 AM, Sergey Vasilenko<br>
>>> <<a href="mailto:svasilenko@mirantis.com">svasilenko@mirantis.com</a>> wrote:<br>
>>>><br>
>>>> After review <a href="https://review.openstack.org/#/c/103280/" target="_blank">https://review.openstack.org/#/c/103280/</a> I have following<br>
>>>> thoughts. This patch looks fine, but huge and has lot of changes in<br>
>>>> deployment logic. Parallel teams work (vmware, melanox) depends on current<br>
>>>> implementation of Neutron in FUEL. I have a some dreads, that they can’t<br>
>>>> refactor his code in the short time remaining.<br>
>>>><br>
>>>> Implementation <a href="https://review.openstack.org/#/c/103280" target="_blank">https://review.openstack.org/#/c/103280</a> has considerably<br>
>>>> less changes in current code of FUEL. Teams from MElanox and VMware based<br>
>>>> their work on current implementation of Neutron. Also this implementation<br>
>>>> was already tested in most deployment modes.<br>
>>>><br>
>>>> On this basis, I suggest:<br>
>>>><br>
>>>> to merge <a href="https://review.openstack.org/#/c/103280" target="_blank">https://review.openstack.org/#/c/103280</a> in fuel-5.1<br>
>>>> To base Neutron implementation for 6.0 get<br>
>>>> <a href="https://review.openstack.org/#/c/103280/" target="_blank">https://review.openstack.org/#/c/103280/</a> and start working for adapt this<br>
>>>> for Juno Neutron.<br>
>>>> Also we should discuss how to make HA-wrapper more pluggable.<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>
>>> --<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>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Mike Scherbakov<br>
>> #mihgen<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>
> --<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>