Open Stack

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 <rvasilets at 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
> <majopela at redhat.com> wrote:
>>
>> On Wed, Aug 10, 2016 at 9:51 PM, Stephen Balukoff <stephen at 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
>> > <majopela at redhat.com> wrote:
>> >>
>> >> On Mon, Aug 8, 2016 at 4:56 PM, Kosnik, Lubosz
>> >> <lubosz.kosnik at 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.kosnik at intel.com
>> >> >
>> >> >> On Aug 8, 2016, at 7:04 AM, Miguel Angel Ajo Pelayo
>> >> >> <majopela at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>