date:20140712

Re: [DISCUSS]CLOUDSTACK-6191

2014-07-12 Thread Daan Hoogland

-0 What does it fix and is the solution bonifide. We should fix the
test suite if it is. The test suite not working is not enough reason
to revert a commit, it should block the test-suite because the system
is broken, not because of the way the test suite works.

Disclaimer: I do not know enough of KVM to make a judgement call. I
just got triggered by the motivation in the mail thread.

On Sat, Jul 12, 2014 at 12:21 AM, Rayees Namathponnan
 wrote:
> +1 Revert now and enable after complete full test in KVM
>
> KVM automation blocked more than 7 days due to this defect
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-7051
>
> Regards,
> Rayees
>
> -Original Message-
> From: Edison Su [mailto:edison...@citrix.com]
> Sent: Friday, July 11, 2014 2:49 PM
> To: dev@cloudstack.apache.org
> Subject: [DISCUSS]CLOUDSTACK-6191
>
> Move the discussion to the list about CloudStack-6191:
> Automation test is blocked by this bug, we need to find a solution. My 
> suggestion is sort-of-revert-the-patch, but still give admin the opportunity 
> to specify the way to optimize KVM volume creation. The reasons:
>
> 1.   End user shouldn't care about how the volume is created, is it 
> sparse,flat/thin-provisoned or whatever technology used by hypervisor. So 
> we'd better not expose this option in disk offering.
>
> 2.It's true that admin does care about how the volume is created, so 
> we can add a global configuration just for the kvm volume creation. For 
> vmware, the option is already there(vmware.create.full.clone to control 
> whether link clone or full clone is used to create volume). We can add an 
> option, something like kvm.qcow2.volume.create.options.
> Comments?



-- 
Daan

CentOS 7 template

2014-07-12 Thread Nux!

Hello,

CentOS 7 has recently been announced, I built a template that can be used with 
CloudStack.
I'd appreciate any sort of feedback as I could only test the KVM images:
http://dl.openvm.eu/cloudstack/centos/vanilla/7/x86_64/

I have also updated the CentOS 6 ones, for those who need them:
http://dl.openvm.eu/cloudstack/centos/vanilla/6/x86_64/

HTH
Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: Resize Volume Question

2014-07-12 Thread Marcus

I just stuck to the standard as seen in cloudstack already, i.e. creating a
volume via api with custom offering and creating a disk offering both
require a size value specified in gibibytes (at least if I remember
correctly), but the system internally uses bytes everywhere (with power of
2) and displays bytes via api.

The shift 30 thing is just a common way to multiply by power of 2. It has
always seemed cleaner to me than 1024*1024*1024 seen elsewhere. Could
probably have a gibToBytes utility somewhere.
On Jul 12, 2014 12:48 AM, "Mike Tutkowski" 
wrote:

> I didn't put this in the ticket, but - historically - when one talks about
> 1 GB in the persistent-storage world, one means 1,000,000,000 bytes (as
> opposed to memory, where 1 GB means 1,073,741,824 bytes).
>
> Some systems try to clarify this by using, for example, GB versus GiB.
>
>
> On Sat, Jul 12, 2014 at 12:11 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > Oh, by the way, that code documentation is still in my sandbox (i.e. not
> > committed). I am working on updating the resize-volume logic for 4.5.
> > Hopefully I'll have it checked in sometime next week.
> >
> >
> > On Sat, Jul 12, 2014 at 12:09 AM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> >> OK, so, I did a couple things:
> >>
> >> 1) I documented the code in the resize-volume area (there were two
> places
> >> that I saw) where we bit shift to convert from GB to bytes.
> >>
> >> 2) I created: https://issues.apache.org/jira/browse/CLOUDSTACK-7101
> >>
> >> The ticket will probably have to wait until a major release because
> >> changing the meaning of that parameter is essentially breaking backward
> >> compatibility.
> >>
> >>
> >> On Fri, Jul 11, 2014 at 8:47 PM, Nitin Mehta 
> >> wrote:
> >>
> >>> Mike - Would you mind creating a bug for it or better still adding a
> >>> comment in the code as a //TODO - standardize it if you can't fix it ?
> >>> I guess currently dev writing new code doesn't have a good reference
> >>> whether to take it as bytes or in GB. That¹s why you are seeing both
> >>> varieties.
> >>>
> >>> Thanks,
> >>> -Nitin
> >>>
> >>> On 11/07/14 6:33 PM, "Mike Tutkowski" 
> >>> wrote:
> >>>
> >>> >Sure, that makes sense - thanks.
> >>> >
> >>> >It's too bad we don't really have a standard for our API in terms of
> how
> >>> >volume sizes are referenced. It seems sometimes we use bytes while
> other
> >>> >times we use GB. I was thinking the units were bytes here, but they
> are
> >>> >GB.
> >>> >
> >>> >
> >>> >On Fri, Jul 11, 2014 at 3:55 PM, Nitin Mehta 
> >>> >wrote:
> >>> >
> >>> >> Probably converting from GB to bytes ? I recall doing that for
> >>> creating
> >>> >> volumes from custom disk offering.
> >>> >>
> >>> >> On 11/07/14 2:07 PM, "Mike Tutkowski"  >
> >>> >> wrote:
> >>> >>
> >>> >> >Hi,
> >>> >> >
> >>> >> >In the resize-volume command, I see this logic:
> >>> >> >
> >>> >> >if (diskOffering.isCustomized() ||
> >>> >> >volume.getVolumeType().equals(Volume.Type.ROOT)) {
> >>> >> >
> >>> >> >newSize = cmd.getSize();
> >>> >> >
> >>> >> >
> >>> >> >if (newSize != null) {
> >>> >> >
> >>> >> >newSize = (newSize << 30);
> >>> >> >
> >>> >> >}
> >>> >> >
> >>> >> >}
> >>> >> >
> >>> >> >Any thoughts on why we are shifting bits 30 places to the left?
> >>> >> >
> >>> >> >I don't recall us doing this in other places for long values?
> >>> >> >
> >>> >> >This is in VolumeApiServiceImpl.resizeVolume.
> >>> >> >
> >>> >> >Thanks!
> >>> >> >--
> >>> >> >*Mike Tutkowski*
> >>> >> >*Senior CloudStack Developer, SolidFire Inc.*
> >>> >> >e: mike.tutkow...@solidfire.com
> >>> >> >o: 303.746.7302
> >>> >> >Advancing the way the world uses the cloud
> >>> >> >* *
> >>> >>
> >>> >>
> >>> >
> >>> >
> >>> >--
> >>> >*Mike Tutkowski*
> >>> >*Senior CloudStack Developer, SolidFire Inc.*
> >>> >e: mike.tutkow...@solidfire.com
> >>> >o: 303.746.7302
> >>> >Advancing the way the world uses the cloud
> >>> >* *
> >>>
> >>>
> >>
> >>
> >> --
> >> *Mike Tutkowski*
> >> *Senior CloudStack Developer, SolidFire Inc.*
> >> e: mike.tutkow...@solidfire.com
> >> o: 303.746.7302
> >> Advancing the way the world uses the cloud
> >> *™*
> >>
> >
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > *™*
> >
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*
>

Re: Resize Volume Question

2014-07-12 Thread Marcus

And I agree it was probably an oversight by the original storage devs,
using powers of 2 instead of 10, since physical hardware doesn't work that
way, but its a bit too late to change now. Its just looks a tad generous I
guess.
On Jul 12, 2014 8:22 PM, "Marcus"  wrote:

> I just stuck to the standard as seen in cloudstack already, i.e. creating
> a volume via api with custom offering and creating a disk offering both
> require a size value specified in gibibytes (at least if I remember
> correctly), but the system internally uses bytes everywhere (with power of
> 2) and displays bytes via api.
>
> The shift 30 thing is just a common way to multiply by power of 2. It has
> always seemed cleaner to me than 1024*1024*1024 seen elsewhere. Could
> probably have a gibToBytes utility somewhere.
> On Jul 12, 2014 12:48 AM, "Mike Tutkowski" 
> wrote:
>
>> I didn't put this in the ticket, but - historically - when one talks about
>> 1 GB in the persistent-storage world, one means 1,000,000,000 bytes (as
>> opposed to memory, where 1 GB means 1,073,741,824 bytes).
>>
>> Some systems try to clarify this by using, for example, GB versus GiB.
>>
>>
>> On Sat, Jul 12, 2014 at 12:11 AM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>> > Oh, by the way, that code documentation is still in my sandbox (i.e. not
>> > committed). I am working on updating the resize-volume logic for 4.5.
>> > Hopefully I'll have it checked in sometime next week.
>> >
>> >
>> > On Sat, Jul 12, 2014 at 12:09 AM, Mike Tutkowski <
>> > mike.tutkow...@solidfire.com> wrote:
>> >
>> >> OK, so, I did a couple things:
>> >>
>> >> 1) I documented the code in the resize-volume area (there were two
>> places
>> >> that I saw) where we bit shift to convert from GB to bytes.
>> >>
>> >> 2) I created: https://issues.apache.org/jira/browse/CLOUDSTACK-7101
>> >>
>> >> The ticket will probably have to wait until a major release because
>> >> changing the meaning of that parameter is essentially breaking backward
>> >> compatibility.
>> >>
>> >>
>> >> On Fri, Jul 11, 2014 at 8:47 PM, Nitin Mehta 
>> >> wrote:
>> >>
>> >>> Mike - Would you mind creating a bug for it or better still adding a
>> >>> comment in the code as a //TODO - standardize it if you can't fix it ?
>> >>> I guess currently dev writing new code doesn't have a good reference
>> >>> whether to take it as bytes or in GB. That¹s why you are seeing both
>> >>> varieties.
>> >>>
>> >>> Thanks,
>> >>> -Nitin
>> >>>
>> >>> On 11/07/14 6:33 PM, "Mike Tutkowski" 
>> >>> wrote:
>> >>>
>> >>> >Sure, that makes sense - thanks.
>> >>> >
>> >>> >It's too bad we don't really have a standard for our API in terms of
>> how
>> >>> >volume sizes are referenced. It seems sometimes we use bytes while
>> other
>> >>> >times we use GB. I was thinking the units were bytes here, but they
>> are
>> >>> >GB.
>> >>> >
>> >>> >
>> >>> >On Fri, Jul 11, 2014 at 3:55 PM, Nitin Mehta > >
>> >>> >wrote:
>> >>> >
>> >>> >> Probably converting from GB to bytes ? I recall doing that for
>> >>> creating
>> >>> >> volumes from custom disk offering.
>> >>> >>
>> >>> >> On 11/07/14 2:07 PM, "Mike Tutkowski" <
>> mike.tutkow...@solidfire.com>
>> >>> >> wrote:
>> >>> >>
>> >>> >> >Hi,
>> >>> >> >
>> >>> >> >In the resize-volume command, I see this logic:
>> >>> >> >
>> >>> >> >if (diskOffering.isCustomized() ||
>> >>> >> >volume.getVolumeType().equals(Volume.Type.ROOT)) {
>> >>> >> >
>> >>> >> >newSize = cmd.getSize();
>> >>> >> >
>> >>> >> >
>> >>> >> >if (newSize != null) {
>> >>> >> >
>> >>> >> >newSize = (newSize << 30);
>> >>> >> >
>> >>> >> >}
>> >>> >> >
>> >>> >> >}
>> >>> >> >
>> >>> >> >Any thoughts on why we are shifting bits 30 places to the left?
>> >>> >> >
>> >>> >> >I don't recall us doing this in other places for long values?
>> >>> >> >
>> >>> >> >This is in VolumeApiServiceImpl.resizeVolume.
>> >>> >> >
>> >>> >> >Thanks!
>> >>> >> >--
>> >>> >> >*Mike Tutkowski*
>> >>> >> >*Senior CloudStack Developer, SolidFire Inc.*
>> >>> >> >e: mike.tutkow...@solidfire.com
>> >>> >> >o: 303.746.7302
>> >>> >> >Advancing the way the world uses the cloud
>> >>> >> >* *
>> >>> >>
>> >>> >>
>> >>> >
>> >>> >
>> >>> >--
>> >>> >*Mike Tutkowski*
>> >>> >*Senior CloudStack Developer, SolidFire Inc.*
>> >>> >e: mike.tutkow...@solidfire.com
>> >>> >o: 303.746.7302
>> >>> >Advancing the way the world uses the cloud
>> >>> >* *
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> *Mike Tutkowski*
>> >> *Senior CloudStack Developer, SolidFire Inc.*
>> >> e: mike.tutkow...@solidfire.com
>> >> o: 303.746.7302
>> >> Advancing the way the world uses the cloud
>> >> *™*
>> >>
>> >
>> >
>> >
>> > --
>> > *Mike Tutkowski*
>> > *Senior CloudStack Developer, SolidFire Inc.*
>> > e: mike.tutkow...@solidfire.c

Question about Global Settings

2014-07-12 Thread Mike Tutkowski

Hi,

I'm doing a code review and had a question that I thought someone might be
able to answer for me:

Do we typically allow vendor-specific config values in Global Settings?

Thanks!

-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
*™*

Fwd: Build failed in Jenkins: cloudstack-rat-master #5015

2014-07-12 Thread Yoshikazu Nojima

When I commit a few minutes ago, I received notification e-mail of
"cloudstack-rat-master" job.
It seems jenkins job or jenkins slave "ubuntu-1" was not configured properly.
Could anyone look into the issue?

-- Forwarded message --
From: Apache Jenkins Server 
Date: 2014-07-13 0:42 GMT-06:00
Subject: Build failed in Jenkins: cloudstack-rat-master #5015
To: cloudstack-comm...@incubator.apache.org, m...@ynojima.net


See 

Changes:

[mail] Remove "--output" option from qemu-img info command call

--
Started by an SCM change
Building remotely on ubuntu-1 (Ubuntu ubuntu) in workspace

Cloning the remote Git repository
Cloning repository https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > git init 
Fetching upstream changes from
https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > git --version
 > git fetch --tags --progress
https://git-wip-us.apache.org/repos/asf/cloudstack.git
+refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url
https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url
https://git-wip-us.apache.org/repos/asf/cloudstack.git
Fetching upstream changes from
https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > git fetch --tags --progress
https://git-wip-us.apache.org/repos/asf/cloudstack.git
+refs/heads/*:refs/remotes/origin/*
 > git rev-parse origin/master^{commit}
Checking out Revision e7392cdac63f1fb835599ef1545139bf6165a078 (origin/master)
 > git config core.sparsecheckout
 > git checkout -f e7392cdac63f1fb835599ef1545139bf6165a078
 > git rev-list 388210c8f91756c42c13ec670387266354cadb1d
[cloudstack-rat-master] $ /bin/bash -xe /tmp/hudson420390257302552639.sh
+ /home/jenkins/tools/maven/latest2/bin/mvn
--projects=org.apache.cloudstack:cloudstack
org.apache.rat:apache-rat-plugin:0.10:check
/tmp/hudson420390257302552639.sh: line 2:
/home/jenkins/tools/maven/latest2/bin/mvn: No such file or directory
Build step 'Execute shell' marked build as failure
Archiving artifacts

Re: [DISCUSS]CLOUDSTACK-6191

CentOS 7 template

Re: Resize Volume Question

Re: Resize Volume Question

Question about Global Settings

Fwd: Build failed in Jenkins: cloudstack-rat-master #5015

6 matches

Site Navigation

Mail list logo

Footer information