<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Sean,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thank you for the response. I understand the rationale you have discussed, but for us this is a problem since we are building a monitoring system and with this behavior it is impossible for us to know if a service is down or not (during a compute failure).</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Any suggestions here on how this situation can be handled?</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thanks</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Regards,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Ramesh</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Sean Mooney <smooney@redhat.com><br>
<b>Sent:</b> Thursday, June 17, 2021 10:48 PM<br>
<b>To:</b> Ramesh Ramanathan B <ramerama@tataelxsi.co.in>; openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org>; Melanie Witt <melwitt@redhat.com><br>
<b>Subject:</b> Re: Nova shows incorrect VM status when compute is down.</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">________________________________<br>
**This is an external email. Please check the sender’s full email address (not just the sender name) and exercise caution before you respond or click any embedded link/attachment.**<br>
________________________________<br>
<br>
On Thu, 2021-06-17 at 14:24 +0000, Ramesh Ramanathan B wrote:<br>
> Dear All,<br>
><br>
> One observation we have while using Open Stack Rocky is, when a<br>
> compute node goes down, the VM status still shows active (the servers<br>
> running in the compute node that went down). Is this the expected<br>
> behavior? Any configurations required to get the right status.<br>
yes this is expected behavior<br>
when the compute agent heartbeat is missed and we do not know the<br>
status of the vms we continue to report them in the last state we knew<br>
of. wedicussed adding an unknow state at onepoint to the api. im not<br>
sure if that has been added yet melanie i think you reviewd or worked<br>
on that?<br>
<br>
there was concern about exposing this as it is exposing info about the<br>
backend hosts for exampel if a cell db connection goes down but the vm<br>
is still active it woudl be incorrect to report the vm state as down<br>
because it actully unknown and in this case the vm is still active.<br>
<br>
in the case were the comptue agent was stopped for mainatnce we also do<br>
not want to set the vms state as down as again stoping the agent will<br>
not prevent the vms form working.<br>
<br>
in either case of the cell connection being tempory disrupted or the<br>
compute agent being stopped reporting the vm as downs in the api could<br>
lead to data currption if you evacuated the vm or a user deleted it and<br>
tried to resue its data voluems for a new vms<br>
<br>
so ingeneral it incorrect to assuem that the vm status in the db refect<br>
the state of the vm on the host if the compute agent is down and its<br>
not correct to udpate the status in the db to down.<br>
making it as unkonw coudl be valide but some operator objected to that<br>
as it was leaking information about there data ceneter(such as they are<br>
currently doing an upgrade/matainece and hvae stopped the agent) to<br>
custoemr that they seee as a security issue.<br>
<br>
<br>
><br>
> In the attached image the compute is down, but the VM status still<br>
> shows active. We are running a data center so it is not practical to<br>
> run nova reset-state for all the servers.<br>
reset-state is not intended to be used for this.<br>
infact reset-state should almost never be used.<br>
you should treat every invocation of reset state as running an arbiraty<br>
sql update query and avoid it unless absolute nessisary.<br>
<br>
> Is there an API to force update Nova to show the correct status? Or<br>
> any configurations missing that is causing this?<br>
><br>
> Thanks<br>
><br>
> Regards,<br>
> Ramesh<br>
><br>
> ________________________________<br>
> Disclaimer: This email and any files transmitted with it are<br>
> confidential and intended solely for the use of the individual or<br>
> entity to whom they are addressed. If you are not the intended<br>
> recipient of this message , or if this message has been addressed to<br>
> you in error, please immediately alert the sender by reply email and<br>
> then delete this message and any attachments. If you are not the<br>
> intended recipient, you are hereby notified that any use,<br>
> dissemination, copying, or storage of this message or its attachments<br>
> is strictly prohibited. Email transmission cannot be guaranteed to be<br>
> secure or error-free, as information could be intercepted, corrupted,<br>
> lost, destroyed, arrive late or incomplete, or contain viruses. The<br>
> sender, therefore, does not accept liability for any errors,<br>
> omissions or contaminations in the contents of this message which<br>
> might have occurred as a result of email transmission. If<br>
> verification is required, please request for a hard-copy version.<br>
> ________________________________<br>
<br>
<br>
</div>
</span></font></div>
</body>
</html>