[nova][dev] 2 weeks until feature freeze
Howdy all, We've about 2 weeks left until feature freeze milestone s-3 on March 7: https://wiki.openstack.org/wiki/Nova/Stein_Release_Schedule Non-client library freeze is in 1 week February 28, so if you need changes released in Stein for os-vif, os-traits, or os-resource-classes, they need to be merged by Feb 28 and the releases will be proposed on Feb 28. Ping us if you need review. The blueprint status tracking etherpad is up-to-date: https://etherpad.openstack.org/p/nova-stein-blueprint-status For our Cycle Themes: Multi-cell operational enhancements: The patch series for the API microversion for handling of down cells (nova side and novaclient side) is complete with one admin docs patch remaining. It is actively being reviewed. Counting quota usage from placement has its implementation done and WIP on test coverage. Cross-cell resize is still making good progress with active code review. Compute nodes able to upgrade and exist with nested resource providers for multiple vGPU types: The libvirt driver reshaper patch is up-to-date and passing CI. There's a comment on the patch pointing out a bit of missing test coverage which needs to be added. Volume-backed user experience and API improvement: The detach boot volume and volume-backed server rebuild patches are active WIP. If you are the owner of an approved blueprint, please: * Add the blueprint if I've missed it * Update the status if it is not accurate * If your blueprint is in the "Wayward changes" section, please upload and update patches as soon as you can, to allow maximum time for review * If your patches are noted as Merge Conflict or WIP or needing an update, please update them and update the status on the etherpad * Add a note under your blueprint if you're no longer able to work on it this cycle Let us know if you have any questions or need assistance with your blueprint. Cheers, -melanie
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
participants (2)
-
Matt Riedemann
-
melanie witt