[infra] [zuul] [placement] Minimizing size/time of test node
I have a work in progress to run a little job in placement that gathers very simple performance numbers on some queries. This is being done as a sort of sanity check. As with many such things it is a bit rough around the edges and I'd like to make it smoother in a variety of ways. The WIP is at https://review.openstack.org/#/c/602484/ One of the ways I'd like to change it is to not rely on devstack. I need only mysql, uwsgi, python and the current revision of placement on the node. The current job uses devstack-minimal as its base but that's overkill and slow. What is the correct base job to use which, as long as I put the files in the right place, will gather the logs I want? Thanks. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On Wed, 2018-11-21 at 12:59 +0000, Chris Dent wrote:
I have a work in progress to run a little job in placement that gathers very simple performance numbers on some queries. This is being done as a sort of sanity check. As with many such things it is a bit rough around the edges and I'd like to make it smoother in a variety of ways.
The WIP is at https://review.openstack.org/#/c/602484/
One of the ways I'd like to change it is to not rely on devstack. I need only mysql, uwsgi, python and the current revision of placement on the node. The current job uses devstack-minimal as its base but that's overkill and slow. out of interest if you did devstack-minimal then set disable-all-services or whatever the macro is and then just enabled mariadb and placement service would there be much of a delta in job time?
What is the correct base job to use which, as long as I put the files in the right place, will gather the logs I want?
Thanks.
On Wed, 21 Nov 2018, Sean Mooney wrote:
On Wed, 2018-11-21 at 12:59 +0000, Chris Dent wrote:
I have a work in progress to run a little job in placement that gathers very simple performance numbers on some queries. This is being done as a sort of sanity check. As with many such things it is a bit rough around the edges and I'd like to make it smoother in a variety of ways.
The WIP is at https://review.openstack.org/#/c/602484/
One of the ways I'd like to change it is to not rely on devstack. I need only mysql, uwsgi, python and the current revision of placement on the node. The current job uses devstack-minimal as its base but that's overkill and slow. out of interest if you did devstack-minimal then set disable-all-services or whatever the macro is and then just enabled mariadb and placement service would there be much of a delta in job time?
That's what the WIP is pretty much doing (now), except that it includes keystone (as lib/placement expects it). It's not super slow, but nor is it super fast, and it seems wasteful for something as tiny as this to not be super fast. I have a followup in progress which is uses the "base" job, but it is taking some time to get right. P.S. Can we make the default reply-to for the new list be the list? This is one of several areas where I disagree with jwz. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On 2018-11-21 15:15:00 +0000 (+0000), Chris Dent wrote: [...]
Can we make the default reply-to for the new list be the list? This is one of several areas where I disagree with jwz.
We discussed it a bit on Monday and concluded that it was better to endure a few weeks of people's replies going to the old lists for messages which came from there through the new list, rather than enact a change in behavior for the new list just after people had started to settle into it. Problem with Reply-To is that you are stuck deciding whether to override the author's Reply-To (if provided) or inconsistently add one for the ML when the author didn't have one. Most modern E-mail clients have a reply-to-list option you can use when replying on mailing lists which include proper RFC 2369 List-* headers (though I too will admit I forget which one to hit sometimes when I'm not paying attention). -- Jeremy Stanley
The issue is a few very popular web clients (maybe one that I use) and some mobile mail apps do not have clear implementations of this feature. Until we have an explicit reply-to, I have to modify every single email I am sending to openstack-discuss so it doesn't also send directly (in this case to you) to the sender as well as the OpenStack-Discuss list. Reply-to-all also doesn't solve this problem, as it (in this case) would add you and openstack-discuss. I agree with Chris on this point. However, as long as we're planning on fixing the reply-to bits for openstack-discuss I'll weather the transitional period. --Morgan On Wed, Nov 21, 2018 at 7:45 AM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2018-11-21 15:15:00 +0000 (+0000), Chris Dent wrote: [...]
Can we make the default reply-to for the new list be the list? This is one of several areas where I disagree with jwz.
We discussed it a bit on Monday and concluded that it was better to endure a few weeks of people's replies going to the old lists for messages which came from there through the new list, rather than enact a change in behavior for the new list just after people had started to settle into it. Problem with Reply-To is that you are stuck deciding whether to override the author's Reply-To (if provided) or inconsistently add one for the ML when the author didn't have one. Most modern E-mail clients have a reply-to-list option you can use when replying on mailing lists which include proper RFC 2369 List-* headers (though I too will admit I forget which one to hit sometimes when I'm not paying attention). -- Jeremy Stanley
On 2018-11-21 07:52:19 -0800 (-0800), Morgan Fainberg wrote:
The issue is a few very popular web clients (maybe one that I use) and some mobile mail apps do not have clear implementations of this feature. Until we have an explicit reply-to, I have to modify every single email I am sending to openstack-discuss so it doesn't also send directly (in this case to you) to the sender as well as the OpenStack-Discuss list.
Yes, if RFC 2369 parsing support is lacking, it's a good opportunity to encourage those services to add it. The client in question also seems to encourage you to top-post, not trim quoted material, and include an unnecessary HTML copy (thankfully it doesn't seem to call remote sites so they can track anyone who reads it without appropriate precautions in their browser). Doesn't seem to me to be a particularly effective platform for participating in technical mailing lists.
Reply-to-all also doesn't solve this problem, as it (in this case) would add you and openstack-discuss. I agree with Chris on this point. However, as long as we're planning on fixing the reply-to bits for openstack-discuss I'll weather the transitional period. [...]
Well, I'm not sure what plan you're thinking is going to "fix" this. We need to avoid adding/modifying Reply-To headers as they are likely to be covered in DKIM signatures. I haven't performed a comprehensive analysis of DKIM-Signature headers found in our archives to determine how many (if any) include Reply-To in their "h" list, but I find plenty of examples on the Internet of MTA configurations doing that so I expect it's a relatively common choice. Also, note that this is a behavior change from the openstack-dev and openstack-sigs MLs (they had reply_goes_to_list=1 set) but not for the openstack and openstack-operators MLs (where it was already reply_goes_to_list=0 instead). -- Jeremy Stanley
participants (4)
-
Chris Dent
-
Jeremy Stanley
-
Morgan Fainberg
-
Sean Mooney