Open Stack

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