[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,
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.
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,
participants (2)
-
Lee Yarwood
-
Matt Riedemann