[openstack-dev] [nova] should we have a stale data indication in "nova list/show"?

Vishvananda Ishaya vishvananda at gmail.com
Thu Jun 26 21:33:37 UTC 2014

On Jun 26, 2014, at 3:58 AM, Day, Phil <philip.day at hp.com> wrote:

>> -----Original Message-----
>> From: Ahmed RAHAL [mailto:arahal at iweb.com]
>> Sent: 25 June 2014 20:25
>> To: openstack-dev at lists.openstack.org
>> Subject: Re: [openstack-dev] [nova] should we have a stale data indication in
>> "nova list/show"?
>> Le 2014-06-25 14:26, Day, Phil a écrit :
>>>> -----Original Message-----
>>>> From: Sean Dague [mailto:sean at dague.net]
>>>> Sent: 25 June 2014 11:49
>>>> To: OpenStack Development Mailing List (not for usage questions)
>>>> Subject: Re: [openstack-dev] [nova] should we have a stale data
>>>> indication in "nova list/show"?
>>> +1 that the state shouldn't be changed.
>>> What about if we exposed the last updated time to users and allowed
>> them to decide if its significant or not ?
>> This would just indicate the last operation's time stamp.
>> There already is a field in nova show called 'updated' that has some kind of
>> indication. I honestly do not know who updates that field, but if anything,
>> this existing field could/should be used.
> Doh ! - yes that is the updated_at value in the DB.    
> I'd missed the last bit of my train of thought on this, which was that we could make the periodic task which checks (and corrects) the instance state update the updated_at timestamp even if the state is unchanged.
> However that does add another DB update per instance every 60 seconds, and I'm with Joe that I'm really not convinced this is taking the Nova view of Status in the right direction.   Better to educate / document the limitation of status as they stand than to try and change it I think.
> Phil

We have an external check that updates the state of instances if the nova-compute fails. We currently put them into ERROR state which is kind of confusing because (as stated earlier in the thread) the instance may be running. It would be nice to have an UNKNOWN state which could be used for this purpose, even if it is an external system that is setting it.

> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140626/2c761600/attachment.pgp>

More information about the OpenStack-dev mailing list