Hi Stephan,
Glad it resolved your issue. When you upgrade CloudStack always make sure to shutdown all usage servers, as sometimes if the usage server tries to add data/entries to cloud_usage db while the upgraded mgmt server is trying to change the schema (of any tables in cloud_usage db) you might end up with bad data or entries. I'm not sure what happened in your environment, but I can speculate a case where usage server tries to add an account but the role_id column might not have added (alter statement did not run for some reason) this would cause NPEs as the column does not exist in the cloud.account table yet. Nevertheless, I'm glad it's not an issue with the code/release itself. Cheers. ________________________________ From: Stephan Seitz <s.se...@secretresearchfacility.com> Sent: 18 August 2016 18:06:49 To: d...@cloudstack.apache.org; users@cloudstack.apache.org Subject: Re: cloudstack-usage no longer working / error saving account to cloud_usage db Hi Rohit, thanks! Having a recent DB backup at hand and only based on guesses, I did some further experiments yesterday :) - Rerun /usr/share/cloudstack-common/scripts/util/migrate- dynamicroles.py - Checked cloudstack-usage 4.8.0.1 instead of 4.9 - Updated back to cloudstack-usage 4.9 ... and magically, it works after I changed the pid of the latest cloud_usage.usage_job to the corresponding pid. Though, I don't think thats the recommended way for a fix as I don't know why it's working... cloud.account shows role_id for every active account. cloud_usage.account now shows role_id for these accounts also. Only PrjAcct-$projectname-$id has role_id set to NULL, but I assume this is correct since Projects are not assigned to roles. Anyway, the metric/quota reports are working! - Stephan Am Donnerstag, den 18.08.2016, 09:03 +0000 schrieb Rohit Yadav: > Hi Stephan, > > > In cloud_usage.account `role_id` can be NULL as there is no user of > this field within the usage server. In cloud.account, the `role_id` > should be automatically populated/migrated when you upgraded. From > your shared db query result, I'm not sure if that's a select query on > cloud.account or cloud_usage.account, can you confirm it? > > > Based on the exception, we can only get that if the account being > saved don't have any role_id defined. With a new account created and > usage records generated, I could not reproduce your issue. It is > likely caused by an account in cloud.account table whose role_id is > NULL. > > > Can you check (and share) that all of your accounts in cloud database > (cloud.account) have non-NULL role_id? Please fix anything that is > NULL. For root admin account type use set role_id=1, for resource > admin set role_id=2, for domain admin set role_id=3 and for user > account set role_type=4; > > > Regards. > > rohit.ya...@shapeblue.com > www.shapeblue.com<http://www.shapeblue.com> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > rohit.ya...@shapeblue.comĀ www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue