On 2/28/2019 7:54 PM, Zhenyu Zheng wrote:
Thanks alot for all the suggestions, so as a summary: 1. do not wipe out the tag when detach 2. free the limit on do not allow attach volume with tag for shelved_offloaded instance if it is a root volume(we can check whether ``is_root`` is True) 2a. if user does not provide any tag, we keep the old tag 2b. if user provide a new tag, we update the new tag 2c. provide a way for user to indicate that I want to null out the previous tag
is my understanding correct?
I think so. For 2c, that gets complicated because the schema for the tag is not nullable [1][2]. So then you're left with leave it or overwrite the tag you had, but you can't go from no tag to tag or vice-versa (without a schema change....). Also one final note here, but multiattach volumes are in the same conundrum, meaning they aren't allowed to attach to a shelved offloaded instance, but if we draw on Dan's use case, picking between detaching a root volume and not being able to attach another multiattach root volume, isn't a good option. So if we're going to do this for tags, I think we ought to do it for multiattach volumes as well. In other words, if the root volume was multiattach before it was detached, then the new root volume can be multiattach, but you can't go from non-multiattach to multiattach while shelved offloaded. The crappy thing about multiattach is it's not a clear attribute on the BDM object, it's buried in the BDM.connection_info [3], but we can still sort that out with a helper method (but it means you can't reset the connection_info when detaching the root volume). [1] https://github.com/openstack/nova/blob/a8c065dea946599a1b07d003cd21409c4cd58... [2] https://github.com/openstack/nova/blob/a8c065dea946599a1b07d003cd21409c4cd58... [3] https://github.com/openstack/nova/blob/a8c065dea946599a1b07d003cd21409c4cd58... -- Thanks, Matt