Indra,

The steps are correct.
Please follow the steps and let me know if you need any help.

This issue got fixed in 4.2-forward branch with this commit: 
38bbfdc89a50bbb9464700d202d1cfa7b7955953

--Sanjay

> -----Original Message-----
> From: Indra Pramana [mailto:in...@sg.or.id]
> Sent: Thursday, October 03, 2013 10:33 AM
> To: Alena Prokharchyk
> Cc: dev@cloudstack.apache.org
> Subject: Re: Unable to create instance after upgrading to CloudStack 4.2.0
> 
> Hi Alena,
> 
> Good day to you, and thank you for your confirmation!
> 
> Can I confirm that this is what I need to do:
> 
> (1) Before upgrade, run the script to insert the records into resource_count
> table for existing accounts/domains.
> (2) Perform the upgrade (from 4.1.1 to 4.2.0);
> (3) After the upgrade, run the API script to populate the records.
> 
> The above will fix the issues on the existing accounts/domains, and future
> accounts/domains will not be affected and will run as per normal after the
> upgrade.
> 
> Can I confirm that my above understanding is correct?
> 
> Looking forward to your reply, thank you.
> 
> Cheers.
> 
> 
> 
> On Thu, Oct 3, 2013 at 11:31 AM, Alena Prokharchyk <
> alena.prokharc...@citrix.com> wrote:
> 
> > 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&d
> omai
> > nId=
> > >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-tabpan
> > >> el&
> > >> 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
> > >> >
> > >>
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >

Reply via email to