I just found this one created recently, and I will try to build on top of it:
https://review.openstack.org/#/c/371807/12 On Wed, Sep 28, 2016 at 1:52 PM, Miguel Angel Ajo Pelayo <majop...@redhat.com> wrote: > Refloating this thread. > > I posted this rfe/bug [1], and I'm planning to come up with an > experimental job that triggers one of the basic neutron/lbaas tests > with octavia. > > I wonder if even picking up the scenario one for now could make sense, > it's not very stable at the moment, but may be spreading the load of > VM creations between two compute nodes could, may be, ease it ? > > [1] https://bugs.launchpad.net/octavia/+bug/1628481 > > On Thu, Aug 11, 2016 at 4:24 PM, Roman Vasilets <rvasil...@mirantis.com> > wrote: >> Hi, >> "need to have something (tempest-plugin) to make sure that integration >> works with nova & neutron" - Its easy to write scenarios that will test that >> octavia works with nova and neutron >> "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)" - Rally is suitable for many kind of tests=) >> Especially for testing at scale! If you have any question how to use Rally >> feel free to ask Rally team! >> >> - Best regards, Roman Vasylets. Rally team member >> >> On Thu, Aug 11, 2016 at 11:46 AM, Miguel Angel Ajo Pelayo >> <majop...@redhat.com> wrote: >>> >>> 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 >> >> >> >> __________________________________________________________________________ >> 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
