<div dir="auto">Just in case I wasn't saying anything about how legit or widespread this use case is, I was just providing an example of how rebuild without real rebuild could be leveraged by operators.<div dir="auto"><br></div><div dir="auto">Regarding cold migrate, I'd love to have then another policy, like <span style="background-color:rgb(255,255,255);font-family:menlo,monaco,consolas,"courier new",monospace;font-size:14px;font-weight:700">os_compute_api:os-migrate-server:migrate-specify-host </span>or smth, so that non-admins could not pick any arbitrary compute and had to rely on scheduler only.</div><div dir="auto"> <br></div><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">пт, 17 мар. 2023 г., 05:50 Mohammed Naser <<a href="mailto:mnaser@vexxhost.com">mnaser@vexxhost.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>
<div>
<div>
<div dir="ltr">IMHO, 0.001% of the time someone might be running rebuild to do something that’s to fix an issue in metadata or something (and probably an operator too) and 99.999% of the time it’s a user expecting a fresh VM</div>
</div>
<div id="m_5329448039690467239ms-outlook-mobile-signature">
<div><br>
</div>
Get <a href="https://aka.ms/o0ukef" target="_blank" rel="noreferrer">Outlook for iOS</a></div>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_5329448039690467239divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Sylvain Bauza <<a href="mailto:sylvain.bauza@gmail.com" target="_blank" rel="noreferrer">sylvain.bauza@gmail.com</a>><br>
<b>Sent:</b> Thursday, March 16, 2023 10:21:14 AM<br>
<b>To:</b> Dmitriy Rabotyagov <<a href="mailto:noonedeadpunk@gmail.com" target="_blank" rel="noreferrer">noonedeadpunk@gmail.com</a>><br>
<b>Cc:</b> openstack-discuss <<a href="mailto:openstack-discuss@lists.openstack.org" target="_blank" rel="noreferrer">openstack-discuss@lists.openstack.org</a>><br>
<b>Subject:</b> Re: [nova][cinder] future of rebuild without reimaging</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div>
<div dir="ltr">Le jeu. 16 mars 2023 à 13:38, Dmitriy Rabotyagov <<a href="mailto:noonedeadpunk@gmail.com" target="_blank" rel="noreferrer">noonedeadpunk@gmail.com</a>> a écrit :<br>
</div>
<blockquote 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 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" rel="noreferrer">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 noreferrer" target="_blank">
https://docs.openstack.org/api-ref/compute/?expanded=rebuild-server-rebuild-action-detail#rebuild-server-rebuild-action</a><br>
><br>
<br><br>
</blockquote>
</div>
</div>
</div>
</div>

</blockquote></div></div>