<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 6 avr. 2023 à 11:25, 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">I think I just came up with another "usecase" or better say missing<br>
functionality. So in case VM is stuck in `unshelving` state, for<br>
example due to messaging issues or smth, there's no clean way of<br>
recovering VM from this state.<br>
Given you will reset state to active - you won't be able to execute<br>
`stop` since VM is not assigned to any compute (and fail with<br>
"instance not ready"), as it was shelved. So then rebuild could be<br>
used, since it will pass VM to be assigned to some host as a result.<br>
Another way around would be of course updating the database, setting<br>
VM back to `shelved_offloaded` and trying to unshelve again, but I<br>
hate messing up with DB.<br>
<br>
I think this kinda brings me back to Sean's point of having an API<br>
call to re-create a VM while keeping it's data, as that would cover<br>
such corner-cases as well.<br>
<br></blockquote><div><br></div><div>FWIW, we agreed on the vPTG to add another separate policy for cold-migrate (when the 'host' parameter is provided), so you could just modify the existing cold-migrate policy (without the 'host' parameter by default) to be able to be called by an end-user.</div><div>If so, an user could ask to move their instances and restart them by this, and if they see some problem, they could then revert the migration.</div><div><br></div><div>I should be working on it by the next weeks hopefully.</div><div>-Sylvain<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">
вт, 21 мар. 2023 г. в 15:59, Dan Smith <<a href="mailto:dms@danplanet.com" target="_blank">dms@danplanet.com</a>>:<br>
><br>
> > Basically they have an additional and unusual compute host recovery<br>
> > process, where a compute host after a failure is brought back by the<br>
> > same name. Then they rebuild the servers on the same compute host<br>
> > where the servers were running before. When the server's disk was<br>
> > backed by a volume, so its content was not lost by the compute host<br>
> > failure, they don't want to lose it either in the recovery process.<br>
> > The evacute operation clearly would be a better fit to do this, but<br>
> > that disallows evacuating to the "same" host. For a long time rebuild<br>
> > just allowed "evacuating to the same host". So they went with it.<br>
><br>
> Aside from the "should this be possible" question, is rebuild even<br>
> required in this case? For the non-volume-backed instances, we need<br>
> rebuild to re-download the image and create the root disk. If it's<br>
> really required for volume-backed instances, I'm guessing there's just<br>
> some trivial amount of state that isn't in place on recovery that the<br>
> rebuild "solves". It is indeed a very odd fringe use-case that is an<br>
> obvious mis-use of the function.<br>
><br>
> > At the moment I did not find a prohibition in the documentation to<br>
> > bring back a failed compute host by the same name. If I missed it or<br>
> > this is not recommended for any reason, please let me know.<br>
><br>
> I'm not sure why this would be specifically documented, but since<br>
> compute nodes are not fully stateless, your scenario is basically<br>
> "delete part of the state of the system and expect things to keep<br>
> working" which I don't think is reasonable (nor something we should need<br>
> to document).<br>
><br>
> Your scenario is basically the same as one where your /var/lib/nova is<br>
> mounted on a disk that doesn't come up after reboot, or on NFS that was<br>
> unavailable at boot. If nova were to say "meh, a bunch of state<br>
> disappeared, I must be a rebuilt compute host" then it would potentially<br>
> destroy (or desynchronize) actual state in other nodes (i.e. the<br>
> database) for a transient/accidental situation. TBH, we might should<br>
> even explicitly *block* rebuild on an instance that appears to be<br>
> missing its on-disk state to avoid users, who don't know the state of the<br>
> infra, from doing this to try to unblock their instances while ops are<br>
> doing maintenance.<br>
><br>
> I will point out that bringing back a compute node under the same name<br>
> (without cleaning the residue first) is strikingly similar to renaming a<br>
> compute host, which we do *not* support. As of Antelope, the compute<br>
> node would detect your scenario as a potential rename and refuse to<br>
> start, again because of state that has been lost in the system. So just<br>
> FYI that an actual blocker to your scenario is coming :)<br>
><br>
> > Clearly in many clouds evacuating can fully replace what they do here.<br>
> > I believe they may have chosen this unusual compute host recovery<br>
> > option to have some kind of recovery process for very small<br>
> > deployments, where you don't always have space to evacuate before you<br>
> > rebuilt the failed compute host. And this collided with a deployment<br>
> > system which reuses host names.<br>
> ><br>
> > At this point I'm not sure if this really belongs to the rebuild<br>
> > operation. Could easily be better addressed in evacuate. Or in the<br>
> > deployment system not reusing hostnames.<br>
><br>
> Evacuate can't work for this case either because it requires the compute<br>
> node to be down to perform. As you note, bringing it back under a<br>
> different name would solve that problem. However, neither "evacuate to<br>
> same host" or "use rebuild for this recovery procedure" are reasonable,<br>
> IMHO.<br>
><br>
> --Dan<br>
><br>
<br>
</blockquote></div></div>