Open Stack

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
<majopela at 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 <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
>>