On Fri, 8 Mar 2019, Matt Riedemann wrote:
On 3/8/2019 8:51 AM, Chris Dent wrote:
We need to decide if we want to do what amounts to a feature freeze exception for Tetsuro's negative member-of handling linked below and work out how/when to fit Mel's allocation ratio work on osc-placement (also below) into the world so people can use it.
Probably not surprisingly I'm a -1 on pushing this stuff in after feature freeze. We have two weeks to RC1 and people should be focusing on testing, bug triage, release notes and other feature documentation.
As part the docs aspect of this, I've made a story in storyboard, and then added tasks to it as a I did a very fast (and incomplete) review of the existing text files that we tend to include under the umbrella of docs. There are 16 or so vague tasks which probably need work. https://storyboard.openstack.org/#!/story/2005190 I wanted to be sure to get these tasks written down, so I used storyboard, but I'm not sure that the way I did was the right choice, but it's start [1]. I hope that as group we can start addressing these next week. Feel free to assign a task to yourself if you're able, and add other tasks. On the member-of feature, I remain inclined to include it if we agree a) it is low impact, and b) that strict adherence to feature freeze in a project as simple as placement, though important, is less important than it is in something like nova. I agree with both of those statement, but we should figure out what the whole group thinks and go with that. I won't be at the meeting on Monday (funeral), but that ^ registers my thoughts on the matter. I hope people will figure something out and also make some doc and other release-related plans.
Also, I'm pretty sure there is nothing in either nova or blazar that is currently not going to merge in stein if this doesn't land in Stein, so based on that it can wait until Train IMO.
For me it has less to do with something waiting on it, and more to do with making things available as they happen.
As for the osc-placement change, I think we can also defer that to Train. It's been talked about since the Dublin PTG and is just now getting implemented, which is good, but also means it's apparently low priority for people and therefore can wait until Train (we won't have another osc-placement release in Stein anyway since clients are frozen now). Also, since it's a client, it will work with older versions of the placement API anyway, i.e. osc-placement in Train should work fine with placement from Queens, so again I don't see a rush here.
That's fine from my standpoint. My default position is if we have a chance to get more stuff out we should try, but if we don't, especially if there's not a lot of clamouring that's fine too. In fact clamouring-oriented-development is probably a good strategy.
There were no nibbles on last week's plea, so I'll say again: If anyone reading this is in a position to provide third party CI with fancy hardware for NUMA, NFV, FPGA, and GPU related integration testing with nova, there's a significant need for that.
There is some discussion happening in OpenLab about this:
Thanks for that, looks like some potential. I have no idea how people keeping track of all the change in our nearby universe lately. At least we have pupdates. [1] Adapting to storyboard is going to involve a lot of experimenting. I think we can make good use of it, but it is different from anything else I've used. To some extent it is an abstraction that one can manipulate as one likes. That makes it potentially powerful, but probably challenging for people who just want to report a bug. We will almost certainly need to do more triage than we've been used to in placement in the past. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent