Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D114C11481 for ; Tue, 6 May 2014 03:56:02 +0000 (UTC) Received: (qmail 45394 invoked by uid 500); 6 May 2014 03:55:57 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 45083 invoked by uid 500); 6 May 2014 03:55:54 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 45075 invoked by uid 99); 6 May 2014 03:55:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 May 2014 03:55:53 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of koushik.das@citrix.com designates 103.14.252.240 as permitted sender) Received: from [103.14.252.240] (HELO SMTP.CITRIX.COM.AU) (103.14.252.240) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 May 2014 03:55:49 +0000 X-IronPort-AV: E=Sophos;i="4.97,994,1389744000"; d="scan'208";a="5214231" Received: from sinaccessns.citrite.net (HELO SINPEX01CL01.citrite.net) ([10.151.60.9]) by sinpip01.citrite.net with ESMTP; 06 May 2014 03:55:27 +0000 Received: from SINPEX01CL02.citrite.net ([169.254.2.163]) by SINPEX01CL01.citrite.net ([169.254.1.186]) with mapi id 14.03.0181.006; Tue, 6 May 2014 11:55:25 +0800 From: Koushik Das To: "" Subject: Re: How is this working? Thread-Topic: How is this working? Thread-Index: AQHPaE2vDbHPaJRdvE2+q/1wcI4lg5sxmoOAgACQjpb//4z3AP//kL2AgAB2zYCAAKe7gA== Date: Tue, 6 May 2014 03:55:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.151.46.1] Content-Type: text/plain; charset="Windows-1252" Content-ID: <41BD36671E968143A85DF6F1ED400288@citrix.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-DLP: SIN1 X-Virus-Checked: Checked by ClamAV on apache.org The dashboard in CS UI is impacted by this. On 05-May-2014, at 11:25 PM, Mike Tutkowski = wrote: > OK, I can log a JIRA ticket for this. >=20 > Thanks >=20 >=20 > On Mon, May 5, 2014 at 11:49 AM, Nitin Mehta wro= te: >=20 >> Ideally, we should deprecate the column since its not used and causes >> confusion. >> Setting to this value wouldn't help because this column is never updated >> regularly. >>=20 >> On 05/05/14 10:28 AM, "Mike Tutkowski" >> wrote: >>=20 >>> How's about I just check this code into master? >>>=20 >>> poolVO.setUsedBytes(mspAnswer.getPoolInfo().getCapacityBytes() - >>> mspAnswer.getPoolInfo().getAvailableBytes()); >>>=20 >>> It is patterned off of the PrimaryDataStoreHelper.attachHost logic, whi= ch >>> looks like this: >>>=20 >>> pool.setUsedBytes(existingInfo.getCapacityBytes() - >>> existingInfo.getAvailableBytes()); >>>=20 >>>=20 >>> On Mon, May 5, 2014 at 10:21 AM, Nitin Mehta >>> wrote: >>>=20 >>>> This column is not used for calculating capacity for pool. >>>> We have always used op host capacity table. Nevertheless please do fil= e >>>> a >>>> bug >>>>=20 >>>> Thanks, >>>> -Nitin >>>> ________________________________________ >>>> From: Mike Tutkowski [mike.tutkowski@solidfire.com] >>>> Sent: Monday, May 05, 2014 9:12 PM >>>> To: dev@cloudstack.apache.org >>>> Subject: Re: How is this working? >>>>=20 >>>> My storage plug-in actually uses a custom host listener, so I have not >>>> encountered this issue. >>>>=20 >>>> I don't remember off hand if it was in 4.2 or 4.3, but at some point >>>> someone changed the storage_pool table's available_bytes column to be >>>> used_bytes. >>>>=20 >>>> It looks like this code you reference was missed. >>>>=20 >>>>=20 >>>> On Mon, May 5, 2014 at 4:35 AM, Koushik Das >>>> wrote: >>>>=20 >>>>> I came across this code snippet in hostConnect() method in >>>>> DefaultHostListener.java. Look at the line where the used bytes is >>>> set on >>>>> the poolVO. This looks like a serious bug. Looking at the history thi= s >>>> code >>>>> has been there since a year. Has anyone encountered any issues with >>>> primary >>>>> storage capacity? >>>>>=20 >>>>> ModifyStoragePoolAnswer mspAnswer =3D (ModifyStoragePoolAnswer)answer= ; >>>>> =8A.. >>>>> StoragePoolVO poolVO =3D this.primaryStoreDao.findById(poolId); >>>>> poolVO.setUsedBytes(mspAnswer.getPoolInfo().getAvailableBytes()); >>>>> poolVO.setCapacityBytes(mspAnswer.getPoolInfo().getCapacityBytes()); >>>>> primaryStoreDao.update(pool.getId(), poolVO); >>>>>=20 >>>>>=20 >>>>> -Koushik >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> *Mike Tutkowski* >>>> *Senior CloudStack Developer, SolidFire Inc.* >>>> e: mike.tutkowski@solidfire.com >>>> o: 303.746.7302 >>>> Advancing the way the world uses the >>>> cloud >>>> * * >>>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>> *Mike Tutkowski* >>> *Senior CloudStack Developer, SolidFire Inc.* >>> e: mike.tutkowski@solidfire.com >>> o: 303.746.7302 >>> Advancing the way the world uses the >>> cloud >>> * * >>=20 >>=20 >=20 >=20 > --=20 > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkowski@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the > cloud > *=99*