[placement][ptg] We like the perfload job, maybe we should rally?

Tetsuro Nakamura tetsuro.nakamura.bc at hco.ntt.co.jp
Thu Apr 11 01:46:04 UTC 2019


I'm not sure about rally,
but I feel better if we have one more performance measurement case to 
exercise the nested/sharing handling path before we go further enabling 
more features on this like the resource provider subtree affinity spec.

The performance depends on the cloud environment, but the performance 
ratio of <nested path>/<non-nested path> could be a kind of an indicator 
which would encourage people to refactor to get more performance 
reducing that ratio.

On 2019/04/09 22:55, Sean Mooney wrote:
> On Tue, 2019-04-09 at 09:33 -0400, Jay Pipes wrote:
>> On 04/09/2019 09:16 AM, Ed Leafe wrote:
>>> On Apr 9, 2019, at 7:45 AM, Chris Dent <cdent+os at anticdent.org> wrote:
>>>>
>>>> In a world of copious time we'd have more of this kind of
>>>> measurement. Should we investigate Rally? It used to be the tool of
>>>> choice for this kind of thing once upon a time. Is it still that
>>>> time?
>>>>
>>>> Or should we continue using more focused and smaller setups, like
>>>> perfload? If so, what should they be?
>>>>
>>>> Or is this something to worry about some other time?
>>>
>>> As we do not have “copious time”, I think that this is not something we need right now. We do have a check in place
>>> in case something goes wrong, so I think our attention can best be directed elsewhere for now.
>>
>> Agree with Ed. :)
> if there was a placement specific tempest plugin woudl that not enmable rally to work automatically.
> im wondering if the gabbi tempest plugin coudl be used to execute the placeim api test via rally with
> some tweeking to the relevent config files?
> 
>>
>> -jay
>>
> 
> 
> 

-- 
Tetsuro Nakamura <tetsuro.nakamura.bc at hco.ntt.co.jp>
NTT Network Service Systems Laboratories
TEL:0422 59 6914(National)/+81 422 59 6914(International)
3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan



More information about the openstack-discuss mailing list