On 2/28/2019 8:36 AM, Matt Riedemann wrote:
Honestly if we're going to do all of that I would rather *not* do the root detach/attach volume stuff if it just means we have to change it later to allow tagging the new root volume.
However, I don't think we really need to wait for driver capabilities traits-based scheduling with a placement request filter either. What is stopping us from simply, within the same microversion for root detach/attach, also lift the restriction on being able to attach a volume to a shelved offloaded instance with a tag? I realize the restriction was there because we didn't know where the instance would unshelve and it could be on a compute host that doesn't support device tags, but that is also true of the initial server create, so if we're going to support the create scenario in the API I don't see why we don't support the shelved offloaded scenario too.
We don't have any policy rules in place against using tags if you're a full VIO shop with only vmware and don't support tags, but we could always add that to 403 requests to use device tags. Otherwise if you're using libvirt then this would already work.
I realize this is a late change in the design for the root volume detach/attach spec, but I think the two need to go together to avoid releasing a half-baked feature.
I've put this on the agenda for today's nova meeting. Here are the options as I see them: 1: lift the restriction in this same microversion so that you can attach volumes to a shelved offloaded server and specify a tag (despite bug 1817927 which we can fix later) 2: reset the tag during root volume detach and don't allow specifying a new tag - this is what we'd get today if we merged Kevin's code as-is 3: don't reset the tag during root volume detach but don't allow overwriting it on root volume attach - this could be poor UX if you need to change the tag 4: same as option 2 but eventually add a new microversion for option 1 thus punting the decision My preferred option is 1 but time is short to be considering this and we might screw something up. I don't think option 3 is viable given the original tag might not make any sense with a new root volume. Options 2 and 4 get us the root volume detach/attach feature in stein as a short-term win but is half-baked since we still have more changes to make later (and another microversion). I know another option is just defer to Train when we have more time to think about this but we're nearly there on this feature so I'd like to get it done if we can reach agreement on the design. -- Thanks, Matt