<div dir="ltr"><div dir="ltr">Thanks all for the feedback, I have update the spec to be more clear about the scope: <a href="https://review.openstack.org/#/c/619161/">https://review.openstack.org/#/c/619161/</a></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 7, 2019 at 4:37 PM Zhenyu Zheng <<a href="mailto:zhengzhenyulixi@gmail.com">zhengzhenyulixi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks alot for the replies, lets wait for some more comments, and I will update the follow-up spec about this within two days.</div><br><div class="gmail_quote"><div dir="ltr">On Sat, Jan 5, 2019 at 7:37 AM melanie witt <<a href="mailto:melwittt@gmail.com" target="_blank">melwittt@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 4 Jan 2019 09:50:46 -0600, Matt Riedemann <<a href="mailto:mriedemos@gmail.com" target="_blank">mriedemos@gmail.com</a>> <br>
wrote:<br>
> On 1/2/2019 2:57 AM, Zhenyu Zheng wrote:<br>
>> I've been working on detach-boot-volume[1] in Stein, we got the initial<br>
>> design merged and while implementing we have meet some new problems and<br>
>> now I'm amending the spec to cover these new problems[2].<br>
> <br>
> [2] is <a href="https://review.openstack.org/#/c/619161/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/619161/</a><br>
> <br>
>><br>
>> The thing I want to discuss for wider opinion is that in the initial<br>
>> design, we planned to support detach root volume for only STOPPED and<br>
>> SHELVED/SHELVE_OFFLOADED instances. But then we found out that we<br>
>> allowed to detach volumes for RESIZED/PAUSED/SOFT_DELETED instances as<br>
>> well. Should we allow detaching root volume for instances in these<br>
>> status too? Cases like RESIZE could be complicated for the revert resize<br>
>> action, and it also seems unnecesary.<br>
> <br>
> The full set of allowed states for attaching and detaching are here:<br>
> <br>
> <a href="https://github.com/openstack/nova/blob/8ef3d253a/nova/compute/api.py#L4187" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/8ef3d253a/nova/compute/api.py#L4187</a><br>
> <br>
> <a href="https://github.com/openstack/nova/blob/8ef3d253a/nova/compute/api.py#L4297" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/8ef3d253a/nova/compute/api.py#L4297</a><br>
> <br>
> Concerning those other states:<br>
> <br>
> RESIZED: There might be a case for attaching/detaching volumes based on<br>
> flavor during a resize, but I'm not sure about the root volume in that<br>
> case (that really sounds more like rebuild with a new image to me, which<br>
> is a different blueprint). I'm also not sure how much people know about<br>
> the ability to do this or what the behavior is on revert if you have<br>
> changed the volumes while the server is resized. If we consider that<br>
> when a user reverts a resize, they want to go back to the way things<br>
> were for the root disk image, then I would think we should not allow<br>
> changing out the root volume while resized.<br>
<br>
Yeah, if someone attaches/detaches a regular volume while the instance <br>
is in VERIFY_RESIZE state and then reverts the resize, I assume we <br>
probably don't attempt to change or restore anything with the volume <br>
attachments to put them back to how they were attached before the <br>
resize. But as you point out, the situation does seem different <br>
regarding a root volume. If a user changes that while in VERIFY_RESIZE <br>
and reverts the resize, and we leave the root volume alone, then they <br>
end up with a different root disk image than they had before the resize. <br>
Which seems weird.<br>
<br>
I agree it seems better not to allow this for now and come back to it <br>
later if people start asking for it.<br>
<br>
> PAUSED: First, I'm not sure how much anyone uses the pause API (or<br>
> suspend for that matter) although most of the virt drivers implement it.<br>
> At one point you could attach volumes to suspended servers as well, but<br>
> because libvirt didn't support it that was removed from the API (yay for<br>
> non-discoverable backend-specific API behavior changes):<br>
> <br>
> <a href="https://review.openstack.org/#/c/83505/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/83505/</a><br>
> <br>
> Anyway, swapping the root volume on a paused instance seems dangerous to<br>
> me, so until someone really has a good use case for it, then I think we<br>
> should avoid that one as well.<br>
> <br>
> SOFT_DELETED: I really don't understand the use case for<br>
> attaching/detaching volumes to/from a (soft) deleted server. If the<br>
> server is deleted and only hanging around because it hasn't been<br>
> reclaimed yet, there are really no guarantees that this would work, so<br>
> again, I would just skip this one for the root volume changes. If the<br>
> user really wants to play with the volumes attached to a soft deleted<br>
> server, they should restore it first.<br>
> <br>
> So in summary, I think we should just not support any of those other<br>
> states for attach/detach root volumes and only focus on stopped or<br>
> shelved instances.<br>
<br>
Again, agree, I think we should just not allow the other states for the <br>
initial implementation and revisit later if it turns out people need these.<br>
<br>
-melanie<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div>
</blockquote></div>