On Wed, Aug 10, 2016 at 9:51 PM, Stephen Balukoff <step...@balukoff.com> wrote: > Miguel-- > > 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.
I guess you mean [1] > People have suggested Rally, but so far nobody has come forth with code, or > a strong desire to push it through. I guess rally is more suited to make sure that things work at scale, to uncover any sort of race conditions (This would be specially beneficial in multinode controllers). But I understand (I can be wrong) that we still need to have something (tempest-plugin) to make sure that integration works with nova & neutron. I'm going to check those patches to see what was the discussion and issues over there (I see this one [1] to start with, which is probably the most important) [1] https://review.openstack.org/#/q/status:open+project:openstack/octavia+branch:master+topic:octavia_basic_lb_scenario [2] https://review.openstack.org/#/c/172199/66..75/.testr.conf > Stephen > > On Tue, Aug 9, 2016 at 5:40 AM, Miguel Angel Ajo Pelayo > <majop...@redhat.com> wrote: >> >> On Mon, Aug 8, 2016 at 4:56 PM, Kosnik, Lubosz <lubosz.kos...@intel.com> >> wrote: >> > Great work with that multi-node setup Miguel. >> >> Thanks, I have to get my hands dirtier with octavia, it's just a tiny >> thing. >> >> > 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. >> >> >> Well, any current tests we run should pass equally well in a multi >> node controller, and that's the point, that, regardless of the >> deployment architecture the behaviour shall not change at all. We may >> not need any specific test. >> >> >> > 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. >> >> I'm not fully aware of what are we running today for octavia, so if >> you can give me some pointers about where are those jobs configured, >> and what do they target, it could be a start, to provide feedback. >> >> What are the current options/tools we're considering? >> >> >> > >> > Cheers, >> > Lubosz Kosnik >> > Cloud Software Engineer OSIC >> > lubosz.kos...@intel.com >> > >> >> On Aug 8, 2016, at 7:04 AM, Miguel Angel Ajo Pelayo >> >> <majop...@redhat.com> wrote: >> >> >> >> Recently, I sent a series of patches [1] to make it easier for >> >> developers to deploy a multi node octavia controller with >> >> n_controllers x [api, cw, hm, hk] with an haproxy in front of the API. >> >> >> >> Since this is the way the service is designed to work (with horizontal >> >> scalability in mind), and we want to have a good guarantee that any >> >> bug related to such configuration is found early, and addressed, I was >> >> thinking that an extra job that runs a two node controller deployment >> >> could be beneficial for the project. >> >> >> >> >> >> If we all believe it makes sense, I would be willing to take on this >> >> work but I'd probably need some pointers and light help, since I've >> >> never dealt with setting up or modifying existing jobs. >> >> >> >> How does this sound? >> >> >> >> >> >> [1] >> >> https://review.openstack.org/#/q/status:merged+project:openstack/octavia+branch:master+topic:multinode-devstack >> >> >> >> >> >> __________________________________________________________________________ >> >> OpenStack Development Mailing List (not for usage questions) >> >> Unsubscribe: >> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev