[nova][cinder][ptg] Summary: Swap volume woes
Hello, tl;dr - No objections to reworking the swap volume API in Train https://etherpad.openstack.org/p/ptg-train-xproj-nova-cinder - L3-18 Summary: - Deprecate the existing swap volume API in Train, remove in U. - Deprecate or straight up remove existing CLI support for the API. - Write up a spec introducing a new API specifically for use by Cinder when retyping or migrating volumes. Potentially using the external events API or policy to lock down access to the API. - Optionally rework the Libvirt virt driver implementation of the API to improve performance and better handle failure cases as suggested by mdbooth. This might include introducing and using a quiesce volume API. I'm personally out for the next two weeks but will start on the above items once back. Cheers, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
On 5/6/2019 8:18 AM, Lee Yarwood wrote:
- Deprecate the existing swap volume API in Train, remove in U.
I don't remember this coming up. Deprecation is one thing if we have an alternative, but removal isn't really an option. Yes we have 410'ed some REST APIs for removed services (nova-network, nova-cells) but for the most part we're married to our REST APIs so we can deprecate things to signal "don't use these anymore" but that doesn't mean we can just delete them. This is why we require a spec for all API changes, because of said marriage. -- Thanks, Matt
On 08-05-19 11:03:17, Matt Riedemann wrote:
On 5/6/2019 8:18 AM, Lee Yarwood wrote:
- Deprecate the existing swap volume API in Train, remove in U.
I don't remember this coming up.
Apologies, I think I trying to suggest that we could deprecate the underlying swap volume logic and replace it with some basic attachment update logic while keeping the same URI etc. IIRC you suggested this would be useful during the session.
Deprecation is one thing if we have an alternative, but removal isn't really an option. Yes we have 410'ed some REST APIs for removed services (nova-network, nova-cells) but for the most part we're married to our REST APIs so we can deprecate things to signal "don't use these anymore" but that doesn't mean we can just delete them. This is why we require a spec for all API changes, because of said marriage.
Understood and I have every intention of writing this up in a spec now I'm back from PTO. Cheers, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76
participants (2)
-
Lee Yarwood
-
Matt Riedemann