[placement][ptg] We like the perfload job, maybe we should rally?
From the etherpad [1]
* Or at least measure more things? Perfload has proven a useful (non-voting) test job for discovering when things are not behaving well under high writes and for having a rough understanding the performance of GET /allocation_candidates 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? [1] https://etherpad.openstack.org/p/placement-ptg-train -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
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. -- Ed Leafe
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. :) -jay
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
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
On Thu, 11 Apr 2019, Tetsuro Nakamura wrote:
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.
This is an excellent point. So I've made a story: https://storyboard.openstack.org/#!/story/2005443 I think that gives us a reasonable next action on this topic and we don't need to go much further than that. So feel free to ignore this topic henceforth, but if you have more to say everyone is more than welcome to keep it going. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
participants (5)
-
Chris Dent
-
Ed Leafe
-
Jay Pipes
-
Sean Mooney
-
Tetsuro Nakamura