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@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@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