Open Stack

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
>