<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 16 mars 2023 à 13:38, Dmitriy Rabotyagov <<a href="mailto:noonedeadpunk@gmail.com">noonedeadpunk@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Maybe I'm missing something, but what are the reasons you would want to<br>
> rebuild an instance without ... rebuilding it?<br>
<br>
I think it might be the case of rescheduling the VM to other compute<br>
without a long-lasting shelve/unshelve and when you don't need to<br>
change the flavor. So kind of self-service when the user does detect<br>
some weirdness, but before bothering the tech team will attempt to<br>
reschedule to another compute on their own.<br>
<br></blockquote><div><br></div><div>We already have an existing API method for this, which is 'cold-migrate' (and it does the same that resize, without changing the flavor)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
ср, 15 мар. 2023 г. в 19:57, Dan Smith <<a href="mailto:dms@danplanet.com" target="_blank">dms@danplanet.com</a>>:<br>
><br>
> >  We have users who use 'rebuild' on volume booted servers before nova<br>
> >  microversion 2.93, relying on the behavior that it keeps the volume as<br>
> >  is. And they would like to keep doing this even after the openstack<br>
> >  distro moves to a(n at least) zed base (sometime in the future).<br>
><br>
> Maybe I'm missing something, but what are the reasons you would want to<br>
> rebuild an instance without ... rebuilding it?<br>
><br>
> I assume it's because you want to redefine the metadata or name or<br>
> something. There's a reason why those things are not easily mutable<br>
> today, and why we had a lot of discussion on how to make user metadata<br>
> mutable on an existing instance in the last cycle. However, I would<br>
> really suggest that we not override "recreate the thing" to "maybe<br>
> recreate the thing or just update a few fields". Instead, for things we<br>
> think really should be mutable on a server at runtime, we should<br>
> probably just do that.<br>
><br>
> Imagine if the way you changed permissions recursively was to run 'rm<br>
> -Rf --no-delete-just-change-ownership'. That would be kinda crazy, but<br>
> that is (IMHO) what "recreate but don't just change $name" means to a<br>
> user.<br>
><br>
> >  As a naive user, it seems to me both behaviors make sense. I can<br>
> >  easily imagine use cases for rebuild with and without reimaging.<br>
><br>
> I think that's because you're already familiar with the difference. For<br>
> users not already in that mindset, I think it probably seems very weird<br>
> that rebuild is destructive in one case and not the other.<br>
><br>
> >  Then there are a few hypothetical situations like:<br>
> >  a) Rebuild gets a new api feature (in a new microversion) which can<br>
> >  never be combined with the do-not-reimage behavior.<br>
> >  b) Rebuild may have a bug, whose fix requires a microversion bump.<br>
> >  This again can never be combined with the old behavior.<br>
> ><br>
> >  What do you think, are these concerns purely theoretical or real?<br>
> >  If we would like to keep having rebuild without reimaging, can we rely<br>
> >  on the old microversion indefinitely?<br>
> >  Alternatively shall we propose and implement a nova spec to explicitly<br>
> >  expose the choice in the rebuild api (just to express the idea: osc<br>
> >  server rebuild --reimage|--no-reimage)?<br>
> ><br>
> > I'm not opposed to challenge the usecases in a spec, for sure.<br>
><br>
> I really want to know what the use-case is for "rebuild but not<br>
> really". And also what "rebuild" means to a user if --no-reimage is<br>
> passed. What's being rebuilt? The docs[0] for the API say very clearly:<br>
><br>
> "This operation recreates the root disk of the server."<br>
><br>
> That was a lie for volume-backed instances for technical reasons. It was<br>
> a bug, not a feature.<br>
><br>
> I also strongly believe that if we're going to add a "but not<br>
> really" flag, it needs to apply to volume-backed and regular instances<br>
> identically. Because that's what the change here was doing - unifying<br>
> the behavior for a single API operation. Going the other direction does<br>
> not seem useful to me.<br>
><br>
> --Dan<br>
><br>
> [0] <a href="https://docs.openstack.org/api-ref/compute/?expanded=rebuild-server-rebuild-action-detail#rebuild-server-rebuild-action" rel="noreferrer" target="_blank">https://docs.openstack.org/api-ref/compute/?expanded=rebuild-server-rebuild-action-detail#rebuild-server-rebuild-action</a><br>
><br>
<br>
</blockquote></div></div>