<div dir="ltr"><div><div><div>Miguel--<br><br></div>There have been a number of tempest patches in the review queue for a long time now, but I think the reason they're not getting attention is that we don't want to have to import a massive amount of tempest code into our repository (which will become stale and need hot-fixing, as has happened with neutron-lbaas on many occasions), and it appears tempest-lib doesn't yet support all the stuff we would need to do with it.<br><br></div>People have suggested Rally, but so far nobody has come forth with code, or a strong desire to push it through.<br><br></div>Stephen<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 9, 2016 at 5:40 AM, Miguel Angel Ajo Pelayo <span dir="ltr"><<a href="mailto:majopela@redhat.com" target="_blank">majopela@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Aug 8, 2016 at 4:56 PM, Kosnik, Lubosz <<a href="mailto:lubosz.kosnik@intel.com">lubosz.kosnik@intel.com</a>> wrote:<br>
> Great work with that multi-node setup Miguel.<br>
<br>
</span>Thanks, I have to get my hands dirtier with octavia, it's just a tiny thing.<br>
<span class=""><br>
> About that multinode Infra is supporting two nodes setup used currently by grenade jobs but in my opinion we don’t have any tests which can cover that type of testing. We’re still struggling with selecting proper tool to test Octavia from integration/functional perspective so probably it’s too early to make it happen.<br>
<br>
<br>
</span>Well, any current tests we run should pass equally well in a multi<br>
node controller, and that's the point, that, regardless of the<br>
deployment architecture the behaviour shall not change at all. We may<br>
not need any specific test.<br>
<span class=""><br>
<br>
> Maybe it’s great start to finally make some decision about testing tools and there will be a lot of work for you after that also with setting up an infra multi-node job for that.<br>
<br>
</span>I'm not fully aware of what are we running today for octavia, so if<br>
you can give me some pointers about where are those jobs configured,<br>
and what do they target, it could be a start, to provide feedback.<br>
<br>
What are the current options/tools we're considering?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
><br>
> Cheers,<br>
> Lubosz Kosnik<br>
> Cloud Software Engineer OSIC<br>
> <a href="mailto:lubosz.kosnik@intel.com">lubosz.kosnik@intel.com</a><br>
><br>
>> On Aug 8, 2016, at 7:04 AM, Miguel Angel Ajo Pelayo <<a href="mailto:majopela@redhat.com">majopela@redhat.com</a>> wrote:<br>
>><br>
>> Recently, I sent a series of patches [1] to make it easier for<br>
>> developers to deploy a multi node octavia controller with<br>
>> n_controllers x [api, cw, hm, hk] with an haproxy in front of the API.<br>
>><br>
>> Since this is the way the service is designed to work (with horizontal<br>
>> scalability in mind), and we want to have a good guarantee that any<br>
>> bug related to such configuration is found early, and addressed, I was<br>
>> thinking that an extra job that runs a two node controller deployment<br>
>> could be beneficial for the project.<br>
>><br>
>><br>
>> If we all believe it makes sense, I would be willing to take on this<br>
>> work but I'd probably need some pointers and light help, since I've<br>
>> never dealt with setting up or modifying existing jobs.<br>
>><br>
>> How does this sound?<br>
>><br>
>><br>
>> [1] <a href="https://review.openstack.org/#/q/status:merged+project:openstack/octavia+branch:master+topic:multinode-devstack" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/q/status:merged+project:<wbr>openstack/octavia+branch:<wbr>master+topic:multinode-<wbr>devstack</a><br>
>><br>
>> ______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>