<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 24, 2015 at 11:02 AM, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, Jun 24, 2015 at 11:01 AM, Joe Gordon <span dir="ltr"><<a href="mailto:joe.gordon0@gmail.com" target="_blank">joe.gordon0@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Wed, Jun 24, 2015 at 10:45 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 06/24/2015 01:31 PM, Joe Gordon wrote:<br>
><br>
><br>
</span><span>> On Tue, Jun 16, 2015 at 9:58 AM, Sean Dague <<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a><br>
</span><div><div>> <mailto:<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>>> wrote:<br>
><br>
>     Back when Nova first wanted to test partial upgrade, we did a bunch of<br>
>     slightly odd conditionals inside of grenade and devstack to make it so<br>
>     that if you were very careful, you could just not stop some of the old<br>
>     services on a single node, upgrade everything else, and as long as the<br>
>     old services didn't stop, they'd be running cached code in memory, and<br>
>     it would look a bit like a 2 node worker not upgraded model. It worked,<br>
>     but it was weird.<br>
><br>
>     There has been some interest by the Nova team to expand what's not being<br>
>     touched, as well as the Neutron team to add partial upgrade testing<br>
>     support. Both are great initiatives, but I think going about it the old<br>
>     way is going to add a lot of complexity in weird places, and not be as<br>
>     good of a test as we really want.<br>
><br>
>     Nodepool now supports allocating multiple nodes. We have a multinode job<br>
>     in Nova regularly testing live migration using this.<br>
><br>
>     If we slice this problem differently, I think we get a better<br>
>     architecture, a much easier way to add new configs, and a much more<br>
>     realistic end test.<br>
><br>
>     Conceptually, use devstack-gate multinode support to set up 2 nodes, an<br>
>     all in one, and a worker. Let grenade upgrade the all in one, leave the<br>
>     worker alone.<br>
><br>
>     I think the only complexity here is the fact that grenade.sh implicitly<br>
>     drives stack.sh. Which means one of:<br>
><br>
>     1) devstack-gate could build the worker first, then run grenade.sh<br>
><br>
>     2) we make it so grenade.sh can execute in parts more easily, so it can<br>
>     hand something else running stack.sh for it.'<br>
><br>
>     3) we make grenade understand the subnode for partial upgrade, so it<br>
>     will run the stack phase on the subnode itself (given credentials).<br>
><br>
>     This kind of approach means deciding which services you don't want to<br>
>     upgrade doesn't require devstack changes, it's just a change of the<br>
>     services on the worker.<br>
><br>
>     We need a volunteer for taking this on, but I think all the follow on<br>
>     partial upgrade support will be much much easier to do after we have<br>
>     this kind of mechanism in place.<br>
><br>
><br>
> I think this is a great approach for the future of partial upgrade<br>
> support in grenade. I would like to point out step 0 here, is to get<br>
> tempest passing consistently in multinode.<br>
><br>
> Currently the neutron job is failing consistently, and nova-network<br>
> fails roughly 10% of the time due<br>
> to <a href="https://bugs.launchpad.net/nova/+bug/1462305" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1462305</a><br>
> and <a href="https://bugs.launchpad.net/nova/+bug/1445569" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1445569</a><br>
<br>
</div></div>Grenade is only running tempest smoke, which is a quite small number of<br>
tests (and not the shelve/unshelve one for instance). I would expect<br>
it's pass rate to be much higher.<br>
<div><div><br></div></div></blockquote><div><br></div></div></div><div>One way to find out. Want to get a multinode tempest smoke job running and see how it looks after running for a few days.</div></div></div></div></blockquote><div><br></div></div></div><div>smoke jobs*, one for nova-net and one for neutron.</div><span class=""><div> </div></span></div></div></div></blockquote><div><br></div><div>Proposal for multinode smoke jobs: <a href="https://review.openstack.org/#/c/195259/">https://review.openstack.org/#/c/195259/</a></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></span></div><br></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>