On 2/22/2019 11:56 AM, melanie witt wrote:
Cross-cell resize is still making good progress with active code review.
Yes and no. I have built the series from the bottom up such that the things which could be merged which are nice to have despite cross-cell resize are at the beginning and some of those are merged, some are +2d from Eric (thanks). Where it starts to get tricky is when I'm making DB schema changes, added the CrossCellWeigher (probably need to move that later in the series as noted on the review), and then the conductor stuff. Again, the conductor stuff is all built from the bottom up, so it's written like: - add compute service methods that are needed for a conductor task - add the conductor task that executes those compute service methods Once I get to the point of being able to get through to VERIFY_RESIZE status, I added a stub in the API so functional tests can run that code (like gibi's bw provider series). Then I iterate on resize confirm using the same pattern - add compute methods and then the conductor task that calls them. Then resize revert after that, and finally at the very end the new policy rule is added to the API which turns it all on. I've got lots of TODOs and FIXMEs later in the series once it gets into the compute/conductor code, and at least one known issue with tracking volume attachments during a revert (exposed in functional testing). But I've also got the "happy path" scenarios passing in functional tests for confirm/revert. To summarize, there is a ton of code out there [1] (38 patches I think?) and I'd love review on it to start getting feedback and have people punch some holes in it, but I know most of it is not going to land in Stein. My hope is to start whittling some of that series down though since as I said, none of it is "on" until the end, but clearly the latter half of the series still needs work. [1] https://review.openstack.org/#/q/status:open+topic:bp/cross-cell-resize -- Thanks, Matt