Hi Indra, Please see inline.
-alena. On 10/2/13 8:21 PM, "Indra Pramana" <in...@sg.or.id> wrote: >Hi Alena, > > >Good day to you, and thank you for your e-mail. > > >Does it mean that later after the upgrade, for every newly created >accounts/domains, I will need to apply the temporary fix all the time? No. You should do it just for the accounts/domains existing before the upgrade. For new accounts, the code should do it automatically as a part of account creation. > Will it cause any issues if I run the MySQL script again later, e.g. >will it cause duplicate entries for existing accounts/domains? There is a constraint in resource_type table on type/account_id and type/domain_id, so before running the script, you have to make sure that the entry doesn't exist already. > > >Looking forward to your reply, thank you. > >Cheers. > > > > >On Thu, Oct 3, 2013 at 2:01 AM, Alena Prokharchyk ><alena.prokharc...@citrix.com> wrote: > >Indra, > > >the issue would impact only existing accounts/domains. For all newly >created accounts/domains, you won't see it. By "temporary" Wei meant that >in the future the problem should be fixed in the CloudStack upgrade code; >so before the fix is in, this temporary > solution should be applied by the customer manually. > > >Answering your other question how to fix the count. For that, you have >to execute the API updateResourceCount. Here is the example: > > >http://localhost:8096/?command=updateResourceCount&account=admin&domainId= >1 > > >-Alena. > > >From: Indra Pramana <in...@sg.or.id> >Reply-To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org> >Date: Wednesday, October 2, 2013 9:05 AM >To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org> > >Subject: Re: Unable to create instance after upgrading to CloudStack 4.2.0 > > > > >Hi Wei Zhou, > > >Thank you for the temporary solution, I tried to execute the scripts and I >can see that the records are being inserted into the resource_count table! >:) > > >mysql> select * from resource_count where account_id=2; >+------+------------+-----------+-------------------+-------+ >| id | account_id | domain_id | type | count | >+------+------------+-----------+-------------------+-------+ >| 17 | 2 | NULL | user_vm | 33 | >| 18 | 2 | NULL | public_ip | 4 | >| 19 | 2 | NULL | volume | 51 | >| 20 | 2 | NULL | snapshot | 0 | >| 21 | 2 | NULL | template | 39 | >| 22 | 2 | NULL | project | 0 | >| 23 | 2 | NULL | network | 1 | >| 24 | 2 | NULL | vpc | 0 | >| 6342 | 2 | NULL | cpu | 0 | >| 6597 | 2 | NULL | memory | 0 | >| 6852 | 2 | NULL | primary_storage | 0 | >| 7107 | 2 | NULL | secondary_storage | 0 | >+------+------------+-----------+-------------------+-------+ >12 rows in set (0.00 sec) > > >When you're saying temporary solution, what do you mean by that and how >will that impact us? Do we need to run the temporary solution regularly in >the future, or only during upgrade? > > >I also noted that the count value of the newly created records are all 0. >How would that impact us, and how it can be updated with the actual value? >Will the data/value be updated over time? > > >Any other things we need to take note of? > > >If this solution works for us, then I will schedule another upgrade >attempt >(the fourth one!) tomorrow. > > >Looking forward to your reply, thank you. > > >Cheers. > > > > > > >On Wed, Oct 2, 2013 at 10:47 PM, Wei ZHOU <ustcweiz...@gmail.com> wrote: > > > >For a temporary solution, log in the database, try again after run >insert into resource_count(domain_id,type) select id,"cpu" from domain; >insert into resource_count(domain_id,type) select id,"memory" from domain; >insert into resource_count(domain_id,type) select id,"primary_storage" >from >domain; >insert into resource_count(domain_id,type) select id,"secondary_storage" >from domain; >insert into resource_count(account_id,type) select id,"cpu" from account; >insert into resource_count(account_id,type) select id,"memory" from >account; >insert into resource_count(account_id,type) select id,"primary_storage" >from account; >insert into resource_count(account_id,type) select id,"secondary_storage" >from account; > > > > > > >2013/10/2 Valery Ciareszka (JIRA) <j...@apache.org> > > >> >> [ >https://issues.apache.org/jira/browse/CLOUDSTACK-4627 ><https://issues.apache.org/jira/browse/CLOUDSTACK-4627>? >> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel& >> focusedCommentId=13784006#comment-13784006 ] >> >> Valery Ciareszka commented on CLOUDSTACK-4627: >> ---------------------------------------------- >> >> Was it really commited to 4.2.0 branch ? I see old version in latest >> source package: >> >> wget >http://www.eu.apache.org/dist/cloudstack/releases/4.2.0/ ><http://www.eu.apache.org/dist/cloudstack/releases/4.2.0/> >> apache-cloudstack-4.2.0-src.tar.bz2 >> tar jxfv apache-cloudstack-4.2.0-src.tar.bz2 >> >> [root@ad011d apache-cloudstack-4.2.0-src]# grep -A9 >> canVmRestartOnAnotherServer >> server/src/com/cloud/storage/VolumeManagerImpl.java >> public boolean canVmRestartOnAnotherServer(long vmId) { >> List<VolumeVO> vols = _volsDao.findCreatedByInstance(vmId); >> for (VolumeVO vol : vols) { >> if (!vol.isRecreatable() && !vol.getPoolType().isShared()) { >> return false; >> } >> } >> return true; >> } >> >> >> > HA not working, User VM wasn't Migrated >> > --------------------------------------- >> > >> > Key: CLOUDSTACK-4627 >> > URL: >https://issues.apache.org/jira/browse/CLOUDSTACK-4627 ><https://issues.apache.org/jira/browse/CLOUDSTACK-4627> >> > Project: CloudStack >> > Issue Type: Bug >> > Security Level: Public(Anyone can view this level - this is the >default.) >> > Components: Hypervisor Controller, KVM, Management Server >> > Affects Versions: 4.2.0 >> > Environment: CentOS 6.3 64bit >> > Reporter: Naoki Sakamoto >> > Assignee: edison su >> > Attachments: 20130906_HA_SystemVM_Migration_OK_But_UserVM_NG.zip, >> 20130909_HA_UserVM_Migration_NG.zip >> > >> > >> > 1. We made one of KVM Host Power OFF by push power button of hardware >> for High Availability Test. >> > 2. Vritual Router / Secodary Storage VM / Console Proxy VM is >>Migrated. >> > But User VM wasn't Migrated. >> >> >> >> -- >> This message was sent by Atlassian JIRA >> (v6.1#6144) >> > > > > > > >2013/10/2 Indra Pramana <in...@sg.or.id> > > >> Hi Wei Zhou, >> >> Thanks for your e-mail. >> >> Do you have any recommendation or suggestion on how we can resolve the >> problem? I am not a CloudStack developer (just a normal user) so we are >at >> loss on how we can resolve this issue. We are not able to upgrade to >4.2.0 >> because of this new problem, after we managed to get around quite a lot >of >> bumps on our road to 4.2.0. >> >> Looking forward to your reply, thank you. >> >> Cheers. >> >> >> >> On Wed, Oct 2, 2013 at 10:25 PM, Wei ZHOU <ustcweiz...@gmail.com> wrote: >> >> > Hi Indra, >> > >> > It is a java file, not a script. >> > ./server/src/com/cloud/server/ConfigurationServerImpl.java >> > >> > > > > > > > > > > > > > > > > >
