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 8BD0910CCC for ; Sat, 26 Oct 2013 05:18:48 +0000 (UTC) Received: (qmail 66777 invoked by uid 500); 26 Oct 2013 05:18:44 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 66749 invoked by uid 500); 26 Oct 2013 05:18:42 -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 66734 invoked by uid 99); 26 Oct 2013 05:18:40 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 26 Oct 2013 05:18:40 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of mike.tutkowski@solidfire.com designates 209.85.219.52 as permitted sender) Received: from [209.85.219.52] (HELO mail-oa0-f52.google.com) (209.85.219.52) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 26 Oct 2013 05:18:34 +0000 Received: by mail-oa0-f52.google.com with SMTP id n10so1772370oag.39 for ; Fri, 25 Oct 2013 22:18:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=+ouZUdI/I//4xGr/fp24iEzvzNq74zXasNYmVDCe5Gk=; b=JAT4YJgAT39vDuM9O0acGLnb5AsYxY8ACkxz5bAXthcPI6NLyn6glN8nLaxU/j0S7f 8zrfuKgSRtUgg6THBKjIyVFAK+vh2Rf0YNYURxDs9h5eANx9ZOs0OvOED0NWYV1uDKEv L/kfFp4PhqB6/rXHCxckNUXQzBVhKTTHEkMuf4UvSdc3WZuHGF/QWxqmaD5ojgCe3dlG macdzkTVMNXRtmdrpjSGCSCtohKwGV+h4lXltLOdwptkAXi2umVX0hoFC5UCBN/Cr8mB VymQVj+YXyuqXHQ+8JFAWVCOmW2RoADC7Tk43OL/rHsgcJM5Wc+be9aCeL3MioNYtwi6 y6uw== X-Gm-Message-State: ALoCoQmm12NAfgn9AQNd0yjJrUCZMlRm8gjxdsF7okhlPVIPaiLnHmxpyvJdlPfJExQ31N0i8Mlk MIME-Version: 1.0 X-Received: by 10.60.51.7 with SMTP id g7mr6184069oeo.6.1382764692845; Fri, 25 Oct 2013 22:18:12 -0700 (PDT) Received: by 10.182.79.130 with HTTP; Fri, 25 Oct 2013 22:18:12 -0700 (PDT) In-Reply-To: References: Date: Fri, 25 Oct 2013 23:18:12 -0600 Message-ID: Subject: Re: VolumeApiServiceImpl Question From: Mike Tutkowski To: "dev@cloudstack.apache.org" Content-Type: multipart/alternative; boundary=001a11c308e0534e3a04e99dfead X-Virus-Checked: Checked by ClamAV on apache.org --001a11c308e0534e3a04e99dfead Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Is this a recent fix, Min? I updated from master a couple days ago and was still having trouble with creating a volume from a disk offering unless I hard-coded something for _maxVolumeSizeInGb. Thanks! On Fri, Oct 25, 2013 at 10:40 PM, Min Chen wrote: > Hi Mike, > > This was caused by missing initialization of _maxVolumeSizeInGb > from > configDao in configuring VolumeApiServiceImpl. I checked in a fix > 694ec684a372c95abf8d1a798714b6f074862816 into master, which should have > fixed this issue. > > Thanks > -min > > On 10/24/13 4:35 PM, "Mike Tutkowski" > wrote: > > >Figured I'd send this out again. > > > >Any thoughts as to why _maxVolumeSizeInGb is never assigned to in > >VolumeApiServiceImpl? > > > >The end result is you cannot create a volume unless you explicitly go in= to > >VolumeApiServiceImpl and do something like assign a high value to > >_maxVolumeSizeInGb. > > > >I opened a JIRA ticket for this issue: > > > >https://issues.apache.org/jira/browse/CLOUDSTACK-4812 > > > > > >On Wed, Oct 2, 2013 at 1:48 PM, Mike Tutkowski > > >> wrote: > > > >> Hi, > >> > >> I'm trying to create a volume from a Disk Offering that specifies a 10 > >>GB > >> disk. > >> > >> When attempting to create a volume from this Disk Offering, I'm told t= he > >> maximum size I can create for a volume is 0 GB. > >> > >> In VolumeApiServiceImpl, I see a private instance variable called > >> _maxVolumeSizeInGb, which appears to be the problem. > >> > >> It is read from, but never written to (its default value is 0 since it > >>is > >> a 'long' member variable). > >> > >> Am I missing something here? > >> > >> Thanks! > >> > >> -- > >> *Mike Tutkowski* > >> *Senior CloudStack Developer, SolidFire Inc.* > >> e: mike.tutkowski@solidfire.com > >> o: 303.746.7302 > >> Advancing the way the world uses the > >>cloud > >> * * > >> > > > > > > > >-- > >*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 *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* --001a11c308e0534e3a04e99dfead--