Open Stack

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