Review Request: format TestCaseExecuteEngine

2013-06-23 Thread daan Hoogland 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12051/
---

Review request for cloudstack and Sebastien Goasguen.


Description
---

format TestCaseExecuteEngine


This addresses bug CLOUDSTACK-3096.


Diffs
-

  tools/marvin/marvin/cloudstackTestClient.py 37380d6 

Diff: https://reviews.apache.org/r/12051/diff/


Testing
---


Thanks,

daan Hoogland

Review Request: format asyncJobMgr

2013-06-23 Thread daan Hoogland 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12052/
---

Review request for cloudstack and Sebastien Goasguen.


Description
---

format asyncJobMgr


This addresses bug CLOUDSTACK-3096.


Diffs
-

  tools/marvin/marvin/asyncJobMgr.py 6984627 

Diff: https://reviews.apache.org/r/12052/diff/


Testing
---


Thanks,

daan Hoogland

Review Request: format cloudstackException

2013-06-23 Thread daan Hoogland 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12053/
---

Review request for cloudstack and Sebastien Goasguen.


Description
---

format cloudstackException


This addresses bug CLOUDSTACK-3096.


Diffs
-

  tools/marvin/marvin/cloudstackException.py 17a06cc 

Diff: https://reviews.apache.org/r/12053/diff/


Testing
---


Thanks,

daan Hoogland

Review Request: format cloudstackTestCase

2013-06-23 Thread daan Hoogland 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12054/
---

Review request for cloudstack and Sebastien Goasguen.


Description
---

format cloudstackTestCase


This addresses bug CLOUDSTACK-3096.


Diffs
-

  tools/marvin/marvin/cloudstackTestCase.py 7e557f8 

Diff: https://reviews.apache.org/r/12054/diff/


Testing
---


Thanks,

daan Hoogland

Review Request: format cloudstackTestClient

2013-06-23 Thread daan Hoogland 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12055/
---

Review request for cloudstack and Sebastien Goasguen.


Description
---

format cloudstackTestClient


This addresses bug CLOUDSTACK-3096.


Diffs
-

  tools/marvin/marvin/cloudstackTestClient.py 37380d6 

Diff: https://reviews.apache.org/r/12055/diff/


Testing
---


Thanks,

daan Hoogland

Re: Review Request: format TestCaseExecuteEngine

2013-06-23 Thread Sebastien Goasguen 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12051/#review22300
---

Ship it!


applied to master 3fdcf1836c22567746c34a42db60505a42fbf6bc
mark review as submitted thx

- Sebastien Goasguen


On June 23, 2013, 2:11 p.m., daan Hoogland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12051/
> ---
> 
> (Updated June 23, 2013, 2:11 p.m.)
> 
> 
> Review request for cloudstack and Sebastien Goasguen.
> 
> 
> Description
> ---
> 
> format TestCaseExecuteEngine
> 
> 
> This addresses bug CLOUDSTACK-3096.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/cloudstackTestClient.py 37380d6 
> 
> Diff: https://reviews.apache.org/r/12051/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> daan Hoogland
> 
>

Re: Review Request: format asyncJobMgr

2013-06-23 Thread Sebastien Goasguen 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12052/#review22301
---

Ship it!


applied to master 34fc209419dc0f9b6d347e7a33371bc0941069b6
mark review as submitted

- Sebastien Goasguen


On June 23, 2013, 2:24 p.m., daan Hoogland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12052/
> ---
> 
> (Updated June 23, 2013, 2:24 p.m.)
> 
> 
> Review request for cloudstack and Sebastien Goasguen.
> 
> 
> Description
> ---
> 
> format asyncJobMgr
> 
> 
> This addresses bug CLOUDSTACK-3096.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/asyncJobMgr.py 6984627 
> 
> Diff: https://reviews.apache.org/r/12052/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> daan Hoogland
> 
>

Re: Review Request: format cloudstackException

2013-06-23 Thread Sebastien Goasguen 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12053/#review22302
---

Ship it!


applied to master 3f4204b8bc5f31196cbd7c8ff8b343eb7e6ce88f
mark review as submitted

- Sebastien Goasguen


On June 23, 2013, 2:25 p.m., daan Hoogland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12053/
> ---
> 
> (Updated June 23, 2013, 2:25 p.m.)
> 
> 
> Review request for cloudstack and Sebastien Goasguen.
> 
> 
> Description
> ---
> 
> format cloudstackException
> 
> 
> This addresses bug CLOUDSTACK-3096.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/cloudstackException.py 17a06cc 
> 
> Diff: https://reviews.apache.org/r/12053/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> daan Hoogland
> 
>

Re: Review Request: format cloudstackTestCase

2013-06-23 Thread Sebastien Goasguen 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12054/#review22303
---

Ship it!


applied to master d53f1c0946ca05504cff4f4af54a6b40413da06b
mark review as submitted

- Sebastien Goasguen


On June 23, 2013, 2:27 p.m., daan Hoogland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12054/
> ---
> 
> (Updated June 23, 2013, 2:27 p.m.)
> 
> 
> Review request for cloudstack and Sebastien Goasguen.
> 
> 
> Description
> ---
> 
> format cloudstackTestCase
> 
> 
> This addresses bug CLOUDSTACK-3096.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/cloudstackTestCase.py 7e557f8 
> 
> Diff: https://reviews.apache.org/r/12054/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> daan Hoogland
> 
>

Re: Review Request: format cloudstackTestClient

2013-06-23 Thread Sebastien Goasguen 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12055/#review22305
---


This was already patched in https://reviews.apache.org/r/12051/
You are missing testCaseExecuteEngine, I think you attached the wrong patch to 
12051.
So now we are only missing the testCaseExecuteEngine

- Sebastien Goasguen


On June 23, 2013, 2:28 p.m., daan Hoogland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12055/
> ---
> 
> (Updated June 23, 2013, 2:28 p.m.)
> 
> 
> Review request for cloudstack and Sebastien Goasguen.
> 
> 
> Description
> ---
> 
> format cloudstackTestClient
> 
> 
> This addresses bug CLOUDSTACK-3096.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/cloudstackTestClient.py 37380d6 
> 
> Diff: https://reviews.apache.org/r/12055/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> daan Hoogland
> 
>

Re: Review Request: format TestCaseExecuteEngine

2013-06-23 Thread daan Hoogland 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12051/
---

(Updated June 23, 2013, 3:54 p.m.)


Review request for cloudstack and Sebastien Goasguen.


Changes
---

wrong patch was attached, now fixed


Description
---

format TestCaseExecuteEngine


This addresses bug CLOUDSTACK-3096.


Diffs (updated)
-

  tools/marvin/marvin/TestCaseExecuteEngine.py 4b64aae 

Diff: https://reviews.apache.org/r/12051/diff/


Testing
---


Thanks,

daan Hoogland

Re: Review Request: format cloudstackTestClient

2013-06-23 Thread daan Hoogland 


> On June 23, 2013, 3:35 p.m., Sebastien Goasguen wrote:
> > This was already patched in https://reviews.apache.org/r/12051/
> > You are missing testCaseExecuteEngine, I think you attached the wrong patch 
> > to 12051.
> > So now we are only missing the testCaseExecuteEngine

You are right, I fixed this in https://reviews.apache.org/r/12051/ for 
tracability.
guess i suffered an assembly line syndrome


- daan


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12055/#review22305
---


On June 23, 2013, 2:28 p.m., daan Hoogland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12055/
> ---
> 
> (Updated June 23, 2013, 2:28 p.m.)
> 
> 
> Review request for cloudstack and Sebastien Goasguen.
> 
> 
> Description
> ---
> 
> format cloudstackTestClient
> 
> 
> This addresses bug CLOUDSTACK-3096.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/cloudstackTestClient.py 37380d6 
> 
> Diff: https://reviews.apache.org/r/12055/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> daan Hoogland
> 
>

Re: Review Request: format TestCaseExecuteEngine

2013-06-23 Thread Sebastien Goasguen 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12051/#review22307
---

Ship it!


ok applied 3e430ccbf07e80656e130fbd42afd5a5fa955af5

- Sebastien Goasguen


On June 23, 2013, 3:54 p.m., daan Hoogland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12051/
> ---
> 
> (Updated June 23, 2013, 3:54 p.m.)
> 
> 
> Review request for cloudstack and Sebastien Goasguen.
> 
> 
> Description
> ---
> 
> format TestCaseExecuteEngine
> 
> 
> This addresses bug CLOUDSTACK-3096.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/TestCaseExecuteEngine.py 4b64aae 
> 
> Diff: https://reviews.apache.org/r/12051/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> daan Hoogland
> 
>

Re: Review Request: format cloudstackTestClient

2013-06-23 Thread Sebastien Goasguen 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12055/#review22308
---


I guess you can discard this one...
since I applied the patch via 12051 as well...

- Sebastien Goasguen


On June 23, 2013, 2:28 p.m., daan Hoogland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12055/
> ---
> 
> (Updated June 23, 2013, 2:28 p.m.)
> 
> 
> Review request for cloudstack and Sebastien Goasguen.
> 
> 
> Description
> ---
> 
> format cloudstackTestClient
> 
> 
> This addresses bug CLOUDSTACK-3096.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/cloudstackTestClient.py 37380d6 
> 
> Diff: https://reviews.apache.org/r/12055/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> daan Hoogland
> 
>

[OFFLINE] July 1 - July 7

2013-06-23 Thread Joe Brockmeier 
Taking vacation first week of July and will offline (for any form of
work purposes) from July 1st through 7th. 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: [DISCUSS] Issue with cloudmonkey-4.1.0-0 on pypi

2013-06-23 Thread David Nalley 
I've created this repo based on Rohit's work to preserve history.

The repo is currently read only. I'd like several reviews of this repo
before I open it up for writes.

https://git-wip-us.apache.org/repos/asf/cloudstack-cloudmonkey.git

--David

On Wed, Jun 19, 2013 at 10:27 PM, David Nalley  wrote:
> On Tue, Jun 18, 2013 at 2:24 PM, Rohit Yadav  wrote:
>> On Tue, Jun 18, 2013 at 9:08 PM, David Nalley  wrote:
>>
>>> On Tue, Jun 18, 2013 at 11:33 AM, Sebastien Goasguen 
>>> wrote:
>>> >
>>> >
>>> >
>>> > On 18 Jun 2013, at 17:08, David Nalley  wrote:
>>> >
>>> >> On Mon, Jun 17, 2013 at 7:00 AM, Prasanna Santhanam 
>>> wrote:
>>> >>> On Sun, Jun 09, 2013 at 10:26:43AM -0400, David Nalley wrote:
>>>  On Sun, Jun 9, 2013 at 7:51 AM, Rohit Yadav 
>>> wrote:
>>> > Hi,
>>> >
>>> > I was about to test CloudStack but the cloudmonkey-4.1.0-0 release
>>> on pypi
>>> > does not bundle failsafe api cache so when I install it I don't get
>>> any api
>>> > commands. The autodiscovery using sync is useful but only with the
>>> > ApiDiscovery plugin which works only for 4.2 and later. For 4.1 and
>>> below I
>>> > think we should, in that case, bundle the cache for all the apis. Or
>>> maybe
>>> > just oss components/plugins?
>>> >
>>> > I'll wait for Chip and others to comment if we want to ship it as it
>>> is or
>>> > bundle the cache against 4.1 release?
>>> >
>>> > Cheers.
>>> 
>>>  Honestly - this is exactly why I've been suggesting[1] that we break
>>>  CloudMonkey (and Marvin) out of the main repo and giving it it's own
>>>  lifecycle. It's far easier/faster to iterate cloudmonkey than all of
>>>  CloudStack and tying it to the slower lifecycle of ACS will continue
>>>  to trouble it IMO.
>>> 
>>>  --David
>>> 
>>>  [1] http://markmail.org/message/wir5vfawex3y22ot
>>> >>>
>>> >>> I haven't given breaking out the project much thought. But it's
>>> >>> certainly a possibility:
>>> >>>
>>> >>> a) However, there are parts of the codebase (checkin tests) that depend
>>> >>> on marvin.
>>> >>>
>>> >>> b) I need to come up with a easier way to update marvin across
>>> >>> cloudstack providers to enable auto-upating marvin's libraries like
>>> >>> cloudmonkey can. For this I've made a couple enhancements to
>>> >>> apidiscovery but it's not in master yet and I don't have it fully
>>> >>> figured out.
>>> >>>
>>> >>> Need some time to think through this.
>>> >>>
>>> >>> --
>>> >>> Prasanna.,
>>> >>>
>>> >>> 
>>> >>> Powered by BigRock.com
>>> >>>
>>> >>
>>> >>
>>> >> OK - are your concerns CM-related? or Marvin only?
>>> >>
>>> >> Any problems I am not seeing with breaking out CloudMonkey?
>>> >>
>>> >> Anyone else have concerns here about breaking out CloudMonkey?
>>> >>
>>> >> --David
>>> >
>>> > Could we talk about it during the hack day and report to the list ? I
>>> for one dont understand how these break out repos would work ...process
>>> wise, release wise, ml wise etc ?
>>>
>>>
>>> Seems like it's something that we def. need to discuss on list.
>>>
>>> Here is my thinking:
>>>
>>> I'd move everything under tools/cli in master to a separate repo - I'd
>>> abandon history (unless someone objects and volunteers to extract all
>>> of that history)
>>>
>>> Releases - they'd be separate, with separate versioning. We'd still
>>> vote on CM releases, but likely at a much faster rate than current
>>> mainline ACS releases.
>>>
>>>
>> Hey David, let's do that. Separate versioning makes sense as cloudmonkey no
>> longer really depends on CloudStack or marvin with its api discovery,
>> though we can keep a failsafe precache or have instructions on how to build
>> one using one's synced cache (which is in ~/.cloudmonkey/cache).
>>
>> I've separated out cloudmonkey in a separate git repo retaining its history
>> using my git-fu; https://github.com/bhaisaab/cloudmonkey
>>
>> It's same as latest master plus some commit on adding the license file from
>> CloudStack's root directory, a README.md file, a Makefile and a .gitignore
>> file.
>>
>> Cheers.
>>
>
>
> AWESOME - thanks for the work on this.
> I'll stand up a RO git repo clone in the next day or so for review.
>
> --David

Re: git commit: Initial commit with LICENSE, NOTICE, and README.

2013-06-23 Thread David Nalley 
Uhhh - can we start with a fresh license and notice file.
There are clearly not some of the things mentioned in LICENSE/NOTICE
in this repo.

--David

On Sun, Jun 23, 2013 at 4:50 PM,   wrote:
> Updated Branches:
>   refs/heads/master [created] 6abd98356
>
>
> Initial commit with LICENSE, NOTICE, and README.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/cloudstack-docs/repo
> Commit: http://git-wip-us.apache.org/repos/asf/cloudstack-docs/commit/6abd9835
> Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-docs/tree/6abd9835
> Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-docs/diff/6abd9835
>
> Branch: refs/heads/master
> Commit: 6abd9835683b9205ec635607510a30cce077146d
> Parents:
> Author: Joe Brockmeier 
> Authored: Sun Jun 23 15:49:55 2013 -0500
> Committer: Joe Brockmeier 
> Committed: Sun Jun 23 15:49:55 2013 -0500
>
> --
>  LICENSE | 688 +++
>  NOTICE  |   2 +
>  README  |  53 +
>  3 files changed, 743 insertions(+)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/6abd9835/LICENSE
> --
> diff --git a/LICENSE b/LICENSE
> new file mode 100644
> index 000..2094d02
> --- /dev/null
> +++ b/LICENSE
> @@ -0,0 +1,688 @@
> +Copyright (c) 2013 The Apache Software Foundation
> +
> +
> + Apache License
> +   Version 2.0, January 2004
> +http://www.apache.org/licenses/
> +
> +   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
> +
> +   1. Definitions.
> +
> +  "License" shall mean the terms and conditions for use, reproduction,
> +  and distribution as defined by Sections 1 through 9 of this document.
> +
> +  "Licensor" shall mean the copyright owner or entity authorized by
> +  the copyright owner that is granting the License.
> +
> +  "Legal Entity" shall mean the union of the acting entity and all
> +  other entities that control, are controlled by, or are under common
> +  control with that entity. For the purposes of this definition,
> +  "control" means (i) the power, direct or indirect, to cause the
> +  direction or management of such entity, whether by contract or
> +  otherwise, or (ii) ownership of fifty percent (50%) or more of the
> +  outstanding shares, or (iii) beneficial ownership of such entity.
> +
> +  "You" (or "Your") shall mean an individual or Legal Entity
> +  exercising permissions granted by this License.
> +
> +  "Source" form shall mean the preferred form for making modifications,
> +  including but not limited to software source code, documentation
> +  source, and configuration files.
> +
> +  "Object" form shall mean any form resulting from mechanical
> +  transformation or translation of a Source form, including but
> +  not limited to compiled object code, generated documentation,
> +  and conversions to other media types.
> +
> +  "Work" shall mean the work of authorship, whether in Source or
> +  Object form, made available under the License, as indicated by a
> +  copyright notice that is included in or attached to the work
> +  (an example is provided in the Appendix below).
> +
> +  "Derivative Works" shall mean any work, whether in Source or Object
> +  form, that is based on (or derived from) the Work and for which the
> +  editorial revisions, annotations, elaborations, or other modifications
> +  represent, as a whole, an original work of authorship. For the purposes
> +  of this License, Derivative Works shall not include works that remain
> +  separable from, or merely link (or bind by name) to the interfaces of,
> +  the Work and Derivative Works thereof.
> +
> +  "Contribution" shall mean any work of authorship, including
> +  the original version of the Work and any modifications or additions
> +  to that Work or Derivative Works thereof, that is intentionally
> +  submitted to Licensor for inclusion in the Work by the copyright owner
> +  or by an individual or Legal Entity authorized to submit on behalf of
> +  the copyright owner. For the purposes of this definition, "submitted"
> +  means any form of electronic, verbal, or written communication sent
> +  to the Licensor or its representatives, including but not limited to
> +  communication on electronic mailing lists, source code control systems,
> +  and issue tracking systems that are managed by, or on behalf of, the
> +  Licensor for the purpose of discussing and improving the Work, but
> +  excluding communication that is conspicuously marked or otherwise
> +  designated in writing by the copyright owner as "Not a Contribution."
> +
> +

Re: git commit: Initial commit with LICENSE, NOTICE, and README.

2013-06-23 Thread Joe Brockmeier 
On Sun, Jun 23, 2013, at 04:01 PM, David Nalley wrote:
> Uhhh - can we start with a fresh license and notice file.
> There are clearly not some of the things mentioned in LICENSE/NOTICE
> in this repo.

NOTICE should have been fine, but I corrected the LICENSE file. 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: [DISCUSS] getting rid of KVM patchdisk

2013-06-23 Thread Hiroaki KAWAI 

Current patch/systemvm/debian is based on debian squeeze,
which kernel is 2.6.32-5-686-bigmem. In that system vm,
cloud-early-config silently fails :
/etc/init.d/cloud-early-config: line 109: /dev/vport0p1: No such file or 
directory

So I've upgraded to wheezy (which includes virtio-console.ko)
# I pushed some patch for this.

I think we need to ANNOUNCE the incompatibility of this,
and hopfuly give some upgrade paths for cloudstack users.


(2013/03/05 7:24), Marcus Sorensen wrote:

I think this just requires an updated system vm (the virtio-serial
portion). I've played a bit with the old debian 2.6.32-5-686-bigmem
one and can't get the device nodes to show up, even though the
/boot/config shows that it has CONFIG_VIRTIO_CONSOLE=y. However, if I
try this with a CentOS 6.3 VM, on a CentOS 6.3 or Ubuntu 12.04 KVM
host it works. So I'm not sure what's being used for the ipv6 update,
but we can probably make one that works. We'll need to install qemu-ga
and start it within the systemvm as well.

On Mon, Mar 4, 2013 at 12:41 PM, Edison Su  wrote:




-Original Message-
From: Marcus Sorensen [mailto:shadow...@gmail.com]
Sent: Sunday, March 03, 2013 12:13 PM
To: cloudstack-...@incubator.apache.org
Subject: [DISCUSS] getting rid of KVM patchdisk

For those who don't know (this probably doesn't matter, but...), when KVM
brings up a system VM, it creates a 'patchdisk' on primary storage. This
patchdisk is used to pass along 1) the authorized_keys file and 2) a 'cmdline'
file that describes to the systemvm startup services all of the various
properties of the system vm.

Example cmdline file:

  template=domP type=secstorage host=172.17.10.10 port=8250 name=s-1-
VM
zone=1 pod=1 guid=s-1-VM
resource=com.cloud.storage.resource.NfsSecondaryStorageResource
instance=SecStorage sslcopy=true role=templateProcessor mtu=1500
eth2ip=192.168.100.170 eth2mask=255.255.255.0 gateway=192.168.100.1
public.network.device=eth2 eth0ip=169.254.1.46 eth0mask=255.255.0.0
eth1ip=172.17.10.150 eth1mask=255.255.255.0 mgmtcidr=172.17.10.0/24
localgw=172.17.10.1 private.network.device=eth1 eth3ip=172.17.10.192
eth3mask=255.255.255.0 storageip=172.17.10.192
storagenetmask=255.255.255.0 storagegateway=172.17.10.1
internaldns1=8.8.4.4 dns1=8.8.8.8

This patch disk has been bugging me for awhile, as it creates a volume that
isn't really tracked anywhere or known about in cloudstack's database. Up
until recently these would just litter the KVM primary storages, but there's
been some triage done to attempt to clean them up when the system vms
go away. It's not perfect. It also can be inefficient for certain primary 
storage
types, for example if you end up creating a bunch of 10MB luns on a SAN for
these.

So my question goes to those who have been working on the system vm.
My first preference (aside from a full system vm redesign, perhaps
something that is controlled via an API) would be to copy these up to the
system vm via SCP or something. But the cloud services start so early on that
this isn't possible. Next would be to inject them into the system vm's root
disk before starting the server, but if we're allowing people to make their
own system vms, can we count on the partitions being what we expect? Also
I don't think this will work for RBD, which qemu directly connects to, with the
host OS unaware of any disk.

Options?


Could you take a look at the status of this projects in KVM?
http://wiki.qemu.org/Features/QAPI/GuestAgent
https://fedoraproject.org/wiki/Features/VirtioSerial

Basically, we need a way to talk to guest VM(sending parameters to KVM guest) 
after VM is booted up. Both VMware/Xenserver has its own way to send parameters 
to guest VM through PV driver, but there is no such thing for KVM few years ago.

Re: [DISCUSS] getting rid of KVM patchdisk

2013-06-23 Thread Marcus Sorensen 
Yes, I brought this up previously and was told that we require systemvm
upgrade between many versions and that it is nothing new. There are other
features in 4.2 as well that require the new system vm, so it will be made
known in the release notes and upgrade instructions.
On Jun 23, 2013 8:33 PM, "Hiroaki KAWAI"  wrote:

> Current patch/systemvm/debian is based on debian squeeze,
> which kernel is 2.6.32-5-686-bigmem. In that system vm,
> cloud-early-config silently fails :
> /etc/init.d/cloud-early-**config: line 109: /dev/vport0p1: No such file
> or directory
> So I've upgraded to wheezy (which includes virtio-console.ko)
> # I pushed some patch for this.
>
> I think we need to ANNOUNCE the incompatibility of this,
> and hopfuly give some upgrade paths for cloudstack users.
>
>
> (2013/03/05 7:24), Marcus Sorensen wrote:
>
>> I think this just requires an updated system vm (the virtio-serial
>> portion). I've played a bit with the old debian 2.6.32-5-686-bigmem
>> one and can't get the device nodes to show up, even though the
>> /boot/config shows that it has CONFIG_VIRTIO_CONSOLE=y. However, if I
>> try this with a CentOS 6.3 VM, on a CentOS 6.3 or Ubuntu 12.04 KVM
>> host it works. So I'm not sure what's being used for the ipv6 update,
>> but we can probably make one that works. We'll need to install qemu-ga
>> and start it within the systemvm as well.
>>
>> On Mon, Mar 4, 2013 at 12:41 PM, Edison Su  wrote:
>>
>>>
>>>
>>>  -Original Message-
 From: Marcus Sorensen [mailto:shadow...@gmail.com]
 Sent: Sunday, March 03, 2013 12:13 PM
 To: 
 cloudstack-dev@incubator.**apache.org
 Subject: [DISCUSS] getting rid of KVM patchdisk

 For those who don't know (this probably doesn't matter, but...), when
 KVM
 brings up a system VM, it creates a 'patchdisk' on primary storage. This
 patchdisk is used to pass along 1) the authorized_keys file and 2) a
 'cmdline'
 file that describes to the systemvm startup services all of the various
 properties of the system vm.

 Example cmdline file:

   template=domP type=secstorage host=172.17.10.10 port=8250 name=s-1-
 VM
 zone=1 pod=1 guid=s-1-VM
 resource=com.cloud.storage.**resource.**NfsSecondaryStorageResource
 instance=SecStorage sslcopy=true role=templateProcessor mtu=1500
 eth2ip=192.168.100.170 eth2mask=255.255.255.0 gateway=192.168.100.1
 public.network.device=eth2 eth0ip=169.254.1.46 eth0mask=255.255.0.0
 eth1ip=172.17.10.150 eth1mask=255.255.255.0 mgmtcidr=172.17.10.0/24
 localgw=172.17.10.1 private.network.device=eth1 eth3ip=172.17.10.192
 eth3mask=255.255.255.0 storageip=172.17.10.192
 storagenetmask=255.255.255.0 storagegateway=172.17.10.1
 internaldns1=8.8.4.4 dns1=8.8.8.8

 This patch disk has been bugging me for awhile, as it creates a volume
 that
 isn't really tracked anywhere or known about in cloudstack's database.
 Up
 until recently these would just litter the KVM primary storages, but
 there's
 been some triage done to attempt to clean them up when the system vms
 go away. It's not perfect. It also can be inefficient for certain
 primary storage
 types, for example if you end up creating a bunch of 10MB luns on a SAN
 for
 these.

 So my question goes to those who have been working on the system vm.
 My first preference (aside from a full system vm redesign, perhaps
 something that is controlled via an API) would be to copy these up to
 the
 system vm via SCP or something. But the cloud services start so early
 on that
 this isn't possible. Next would be to inject them into the system vm's
 root
 disk before starting the server, but if we're allowing people to make
 their
 own system vms, can we count on the partitions being what we expect?
 Also
 I don't think this will work for RBD, which qemu directly connects to,
 with the
 host OS unaware of any disk.

 Options?

>>>
>>> Could you take a look at the status of this projects in KVM?
>>> http://wiki.qemu.org/Features/**QAPI/GuestAgent
>>> https://fedoraproject.org/**wiki/Features/VirtioSerial
>>>
>>> Basically, we need a way to talk to guest VM(sending parameters to KVM
>>> guest) after VM is booted up. Both VMware/Xenserver has its own way to send
>>> parameters to guest VM through PV driver, but there is no such thing for
>>> KVM few years ago.
>>>
>>
>

Re: [DISCUSS] getting rid of KVM patchdisk

2013-06-23 Thread Marcus Sorensen 
I personally thought it had been publicized pretty well on various threads
that there is a new system vm for master/4.2, but if you were unaware of
it, do you think more needs to be done to call it out and make it known to
the devs working on it?
On Jun 23, 2013 8:33 PM, "Hiroaki KAWAI"  wrote:

> Current patch/systemvm/debian is based on debian squeeze,
> which kernel is 2.6.32-5-686-bigmem. In that system vm,
> cloud-early-config silently fails :
> /etc/init.d/cloud-early-**config: line 109: /dev/vport0p1: No such file
> or directory
> So I've upgraded to wheezy (which includes virtio-console.ko)
> # I pushed some patch for this.
>
> I think we need to ANNOUNCE the incompatibility of this,
> and hopfuly give some upgrade paths for cloudstack users.
>
>
> (2013/03/05 7:24), Marcus Sorensen wrote:
>
>> I think this just requires an updated system vm (the virtio-serial
>> portion). I've played a bit with the old debian 2.6.32-5-686-bigmem
>> one and can't get the device nodes to show up, even though the
>> /boot/config shows that it has CONFIG_VIRTIO_CONSOLE=y. However, if I
>> try this with a CentOS 6.3 VM, on a CentOS 6.3 or Ubuntu 12.04 KVM
>> host it works. So I'm not sure what's being used for the ipv6 update,
>> but we can probably make one that works. We'll need to install qemu-ga
>> and start it within the systemvm as well.
>>
>> On Mon, Mar 4, 2013 at 12:41 PM, Edison Su  wrote:
>>
>>>
>>>
>>>  -Original Message-
 From: Marcus Sorensen [mailto:shadow...@gmail.com]
 Sent: Sunday, March 03, 2013 12:13 PM
 To: 
 cloudstack-dev@incubator.**apache.org
 Subject: [DISCUSS] getting rid of KVM patchdisk

 For those who don't know (this probably doesn't matter, but...), when
 KVM
 brings up a system VM, it creates a 'patchdisk' on primary storage. This
 patchdisk is used to pass along 1) the authorized_keys file and 2) a
 'cmdline'
 file that describes to the systemvm startup services all of the various
 properties of the system vm.

 Example cmdline file:

   template=domP type=secstorage host=172.17.10.10 port=8250 name=s-1-
 VM
 zone=1 pod=1 guid=s-1-VM
 resource=com.cloud.storage.**resource.**NfsSecondaryStorageResource
 instance=SecStorage sslcopy=true role=templateProcessor mtu=1500
 eth2ip=192.168.100.170 eth2mask=255.255.255.0 gateway=192.168.100.1
 public.network.device=eth2 eth0ip=169.254.1.46 eth0mask=255.255.0.0
 eth1ip=172.17.10.150 eth1mask=255.255.255.0 mgmtcidr=172.17.10.0/24
 localgw=172.17.10.1 private.network.device=eth1 eth3ip=172.17.10.192
 eth3mask=255.255.255.0 storageip=172.17.10.192
 storagenetmask=255.255.255.0 storagegateway=172.17.10.1
 internaldns1=8.8.4.4 dns1=8.8.8.8

 This patch disk has been bugging me for awhile, as it creates a volume
 that
 isn't really tracked anywhere or known about in cloudstack's database.
 Up
 until recently these would just litter the KVM primary storages, but
 there's
 been some triage done to attempt to clean them up when the system vms
 go away. It's not perfect. It also can be inefficient for certain
 primary storage
 types, for example if you end up creating a bunch of 10MB luns on a SAN
 for
 these.

 So my question goes to those who have been working on the system vm.
 My first preference (aside from a full system vm redesign, perhaps
 something that is controlled via an API) would be to copy these up to
 the
 system vm via SCP or something. But the cloud services start so early
 on that
 this isn't possible. Next would be to inject them into the system vm's
 root
 disk before starting the server, but if we're allowing people to make
 their
 own system vms, can we count on the partitions being what we expect?
 Also
 I don't think this will work for RBD, which qemu directly connects to,
 with the
 host OS unaware of any disk.

 Options?

>>>
>>> Could you take a look at the status of this projects in KVM?
>>> http://wiki.qemu.org/Features/**QAPI/GuestAgent
>>> https://fedoraproject.org/**wiki/Features/VirtioSerial
>>>
>>> Basically, we need a way to talk to guest VM(sending parameters to KVM
>>> guest) after VM is booted up. Both VMware/Xenserver has its own way to send
>>> parameters to guest VM through PV driver, but there is no such thing for
>>> KVM few years ago.
>>>
>>
>

Re: [DISCUSS] getting rid of KVM patchdisk

2013-06-23 Thread Hiroaki KAWAI 

No I don't think we need to make such effort (sending emails) for devs,
I think we should fix the code itself (and comments in the codes)
because we're devs.

(2013/06/24 12:20), Marcus Sorensen wrote:

I personally thought it had been publicized pretty well on various threads
that there is a new system vm for master/4.2, but if you were unaware of
it, do you think more needs to be done to call it out and make it known to
the devs working on it?
On Jun 23, 2013 8:33 PM, "Hiroaki KAWAI"  wrote:


Current patch/systemvm/debian is based on debian squeeze,
which kernel is 2.6.32-5-686-bigmem. In that system vm,
cloud-early-config silently fails :
/etc/init.d/cloud-early-**config: line 109: /dev/vport0p1: No such file
or directory
So I've upgraded to wheezy (which includes virtio-console.ko)
# I pushed some patch for this.

I think we need to ANNOUNCE the incompatibility of this,
and hopfuly give some upgrade paths for cloudstack users.


(2013/03/05 7:24), Marcus Sorensen wrote:


I think this just requires an updated system vm (the virtio-serial
portion). I've played a bit with the old debian 2.6.32-5-686-bigmem
one and can't get the device nodes to show up, even though the
/boot/config shows that it has CONFIG_VIRTIO_CONSOLE=y. However, if I
try this with a CentOS 6.3 VM, on a CentOS 6.3 or Ubuntu 12.04 KVM
host it works. So I'm not sure what's being used for the ipv6 update,
but we can probably make one that works. We'll need to install qemu-ga
and start it within the systemvm as well.

On Mon, Mar 4, 2013 at 12:41 PM, Edison Su  wrote:




  -Original Message-

From: Marcus Sorensen [mailto:shadow...@gmail.com]
Sent: Sunday, March 03, 2013 12:13 PM
To: cloudstack-dev@incubator.**apache.org
Subject: [DISCUSS] getting rid of KVM patchdisk

For those who don't know (this probably doesn't matter, but...), when
KVM
brings up a system VM, it creates a 'patchdisk' on primary storage. This
patchdisk is used to pass along 1) the authorized_keys file and 2) a
'cmdline'
file that describes to the systemvm startup services all of the various
properties of the system vm.

Example cmdline file:

   template=domP type=secstorage host=172.17.10.10 port=8250 name=s-1-
VM
zone=1 pod=1 guid=s-1-VM
resource=com.cloud.storage.**resource.**NfsSecondaryStorageResource
instance=SecStorage sslcopy=true role=templateProcessor mtu=1500
eth2ip=192.168.100.170 eth2mask=255.255.255.0 gateway=192.168.100.1
public.network.device=eth2 eth0ip=169.254.1.46 eth0mask=255.255.0.0
eth1ip=172.17.10.150 eth1mask=255.255.255.0 mgmtcidr=172.17.10.0/24
localgw=172.17.10.1 private.network.device=eth1 eth3ip=172.17.10.192
eth3mask=255.255.255.0 storageip=172.17.10.192
storagenetmask=255.255.255.0 storagegateway=172.17.10.1
internaldns1=8.8.4.4 dns1=8.8.8.8

This patch disk has been bugging me for awhile, as it creates a volume
that
isn't really tracked anywhere or known about in cloudstack's database.
Up
until recently these would just litter the KVM primary storages, but
there's
been some triage done to attempt to clean them up when the system vms
go away. It's not perfect. It also can be inefficient for certain
primary storage
types, for example if you end up creating a bunch of 10MB luns on a SAN
for
these.

So my question goes to those who have been working on the system vm.
My first preference (aside from a full system vm redesign, perhaps
something that is controlled via an API) would be to copy these up to
the
system vm via SCP or something. But the cloud services start so early
on that
this isn't possible. Next would be to inject them into the system vm's
root
disk before starting the server, but if we're allowing people to make
their
own system vms, can we count on the partitions being what we expect?
Also
I don't think this will work for RBD, which qemu directly connects to,
with the
host OS unaware of any disk.

Options?



Could you take a look at the status of this projects in KVM?
http://wiki.qemu.org/Features/**QAPI/GuestAgent
https://fedoraproject.org/**wiki/Features/VirtioSerial

Basically, we need a way to talk to guest VM(sending parameters to KVM
guest) after VM is booted up. Both VMware/Xenserver has its own way to send
parameters to guest VM through PV driver, but there is no such thing for
KVM few years ago.

Re: [DISCUSS] Issue with cloudmonkey-4.1.0-0 on pypi

2013-06-23 Thread Rohit Yadav 
On Mon, Jun 24, 2013 at 2:20 AM, David Nalley  wrote:

> I've created this repo based on Rohit's work to preserve history.
>
>
Great, thanks David. Maybe fix the repo description to "Apache CloudStack
CLI" etc.


> The repo is currently read only. I'd like several reviews of this repo
> before I open it up for writes.
>
> https://git-wip-us.apache.org/repos/asf/cloudstack-cloudmonkey.git


+1 review license, docs, any other thing that needs to be fixed.

Cheers.


>
>
> --David
>
> On Wed, Jun 19, 2013 at 10:27 PM, David Nalley  wrote:
> > On Tue, Jun 18, 2013 at 2:24 PM, Rohit Yadav 
> wrote:
> >> On Tue, Jun 18, 2013 at 9:08 PM, David Nalley  wrote:
> >>
> >>> On Tue, Jun 18, 2013 at 11:33 AM, Sebastien Goasguen  >
> >>> wrote:
> >>> >
> >>> >
> >>> >
> >>> > On 18 Jun 2013, at 17:08, David Nalley  wrote:
> >>> >
> >>> >> On Mon, Jun 17, 2013 at 7:00 AM, Prasanna Santhanam  >
> >>> wrote:
> >>> >>> On Sun, Jun 09, 2013 at 10:26:43AM -0400, David Nalley wrote:
> >>>  On Sun, Jun 9, 2013 at 7:51 AM, Rohit Yadav 
> >>> wrote:
> >>> > Hi,
> >>> >
> >>> > I was about to test CloudStack but the cloudmonkey-4.1.0-0
> release
> >>> on pypi
> >>> > does not bundle failsafe api cache so when I install it I don't
> get
> >>> any api
> >>> > commands. The autodiscovery using sync is useful but only with
> the
> >>> > ApiDiscovery plugin which works only for 4.2 and later. For 4.1
> and
> >>> below I
> >>> > think we should, in that case, bundle the cache for all the
> apis. Or
> >>> maybe
> >>> > just oss components/plugins?
> >>> >
> >>> > I'll wait for Chip and others to comment if we want to ship it
> as it
> >>> is or
> >>> > bundle the cache against 4.1 release?
> >>> >
> >>> > Cheers.
> >>> 
> >>>  Honestly - this is exactly why I've been suggesting[1] that we
> break
> >>>  CloudMonkey (and Marvin) out of the main repo and giving it it's
> own
> >>>  lifecycle. It's far easier/faster to iterate cloudmonkey than all
> of
> >>>  CloudStack and tying it to the slower lifecycle of ACS will
> continue
> >>>  to trouble it IMO.
> >>> 
> >>>  --David
> >>> 
> >>>  [1] http://markmail.org/message/wir5vfawex3y22ot
> >>> >>>
> >>> >>> I haven't given breaking out the project much thought. But it's
> >>> >>> certainly a possibility:
> >>> >>>
> >>> >>> a) However, there are parts of the codebase (checkin tests) that
> depend
> >>> >>> on marvin.
> >>> >>>
> >>> >>> b) I need to come up with a easier way to update marvin across
> >>> >>> cloudstack providers to enable auto-upating marvin's libraries like
> >>> >>> cloudmonkey can. For this I've made a couple enhancements to
> >>> >>> apidiscovery but it's not in master yet and I don't have it fully
> >>> >>> figured out.
> >>> >>>
> >>> >>> Need some time to think through this.
> >>> >>>
> >>> >>> --
> >>> >>> Prasanna.,
> >>> >>>
> >>> >>> 
> >>> >>> Powered by BigRock.com
> >>> >>>
> >>> >>
> >>> >>
> >>> >> OK - are your concerns CM-related? or Marvin only?
> >>> >>
> >>> >> Any problems I am not seeing with breaking out CloudMonkey?
> >>> >>
> >>> >> Anyone else have concerns here about breaking out CloudMonkey?
> >>> >>
> >>> >> --David
> >>> >
> >>> > Could we talk about it during the hack day and report to the list ? I
> >>> for one dont understand how these break out repos would work ...process
> >>> wise, release wise, ml wise etc ?
> >>>
> >>>
> >>> Seems like it's something that we def. need to discuss on list.
> >>>
> >>> Here is my thinking:
> >>>
> >>> I'd move everything under tools/cli in master to a separate repo - I'd
> >>> abandon history (unless someone objects and volunteers to extract all
> >>> of that history)
> >>>
> >>> Releases - they'd be separate, with separate versioning. We'd still
> >>> vote on CM releases, but likely at a much faster rate than current
> >>> mainline ACS releases.
> >>>
> >>>
> >> Hey David, let's do that. Separate versioning makes sense as
> cloudmonkey no
> >> longer really depends on CloudStack or marvin with its api discovery,
> >> though we can keep a failsafe precache or have instructions on how to
> build
> >> one using one's synced cache (which is in ~/.cloudmonkey/cache).
> >>
> >> I've separated out cloudmonkey in a separate git repo retaining its
> history
> >> using my git-fu; https://github.com/bhaisaab/cloudmonkey
> >>
> >> It's same as latest master plus some commit on adding the license file
> from
> >> CloudStack's root directory, a README.md file, a Makefile and a
> .gitignore
> >> file.
> >>
> >> Cheers.
> >>
> >
> >
> > AWESOME - thanks for the work on this.
> > I'll stand up a RO git repo clone in the next day or so for review.
> >
> > --David
>

Re: [VOTE] Update by-laws to add section for non-technical decision making (Was: Re: [RESULTS][SUMMARY][DISCUSS][VOTE] List CloudStack related books on the website)

2013-06-23 Thread Mathias Mullins 
Noah, 

I agree that there needs to be a delineation. Here's my option on wording
describing what is non-technical:

+3.4.2. Non-Technical Decisions

+Non-technical decisions should normally be made by the entire community
using
+discussion-lead consensus-building, and not through formal voting.
+
+Non-technical decisions are defined as a decision that do not directly
affect
+the code in any branch of the project.
+Including coding, testing, documentation or management of the code base.
+
+Non-technical decisions can be made on whichever project mailing list is
most
+appropriate.
+
+Non-technical decisions cannot be vetoed, but if there is strong
opposition
+a formal vote can be used to resolve the dispute.
+
+If a formal vote is started for a non-technical decision, the vote will be
held
+as a lazy 2/3 majority of active committers.
+
+Any user, contributor, committer or PMC member can initiate a
non-technical
+decision making process.



Matt Mullins
Cloud Platforms Implementation Engineer
Worldwide Cloud Services ­ Citrix System, Inc.
+1 (407) 920-1107 ­ Office/Cell Phone
matt.mull...@citrix.com






On 6/20/13 11:59 AM, "Noah Slater"  wrote:

>Less terse follow up... ;)
>
>Note that our current by-laws effectively state that any technical
>decision
>needs to happen on dev@. I am just clarifying the intent.
>
>Note also that we currently do not define what a "technical decision" is,
>but it is my opinion that this is any decision which relates to the
>CloudStack source code. (We might want to make it a little broader than
>that. Open to suggestions.)
>
>Almost everything we do involves technology. Whether that is editing the
>website, wiki, JIRA, mailing lists, etc. That doesn't mean that those
>activities are "technical activities" or involve "technical decisions".
>
>Do you think our by-laws need a section clarifying technical vs.
>non-technical? What should it say?
>
>
>On 20 June 2013 15:14, Joe Brockmeier  wrote:
>
>> On Thu, Jun 20, 2013, at 08:21 AM, Noah Slater wrote:
>> > Devs,
>> >
>> > I would like to call a vote on the following modification to our
>>by-laws.
>> > This is in response to the
>> >
>> > Summary of changes:
>> >
>> > * Addition of "3.4.2. Non-Technical Decisions" section. This specifies
>> > that
>> > non-technical decisions can be made on any appropriate list (i.e.
>> > marketing@)
>>
>> Erm. Does this mean that marketing can't make any technical decisions
>> about the Web site, for instance?
>>
>> I think this needs to be better worded.
>>
>>
>> Best,
>>
>> jzb
>> --
>> Joe Brockmeier
>> j...@zonker.net
>> Twitter: @jzb
>> http://www.dissociatedpress.net/
>>
>
>
>
>-- 
>NS

Re: [DISCUSS] getting rid of KVM patchdisk

2013-06-23 Thread Prasanna Santhanam 
Kawai-san,

commit 009da930580fba039b4b8a7532a8a6809d00ed02
+ patches/systemvm/debian/buildsystemvm.sh

The file under there is not used to build systemvm templates as recommended
anymore. The new way to build systemVMs is using veewee-vagrant definitions [1]
and the definition is based on a Debian 7.0.0 Wheezy image

cloudstack/tools/appliance/definitions/systemvmtemplate(branch:master*) ?? cat 
definition.rb | grep debian
  6   :iso_file => "debian-7.0.0-i386-netinst.iso",
  7   :iso_src => 
"http://cdimage.debian.org/mirror/cdimage/archive/7.0.0/i386/iso-cd/debian-7.0.0-i386-netinst.iso";,

We should deprecate the old script now (unless I've misunderstood your change
completely and you were using 4.1)

[1] https://cwiki.apache.org/confluence/x/UlHVAQ


On Mon, Jun 24, 2013 at 12:35:07PM +0900, Hiroaki KAWAI wrote:
> No I don't think we need to make such effort (sending emails) for devs,
> I think we should fix the code itself (and comments in the codes)
> because we're devs.
> 
> (2013/06/24 12:20), Marcus Sorensen wrote:
> >I personally thought it had been publicized pretty well on various threads
> >that there is a new system vm for master/4.2, but if you were unaware of
> >it, do you think more needs to be done to call it out and make it known to
> >the devs working on it?
> >On Jun 23, 2013 8:33 PM, "Hiroaki KAWAI"  wrote:
> >
> >>Current patch/systemvm/debian is based on debian squeeze,
> >>which kernel is 2.6.32-5-686-bigmem. In that system vm,
> >>cloud-early-config silently fails :
> >>/etc/init.d/cloud-early-**config: line 109: /dev/vport0p1: No such file
> >>or directory
> >>So I've upgraded to wheezy (which includes virtio-console.ko)
> >># I pushed some patch for this.
> >>
> >>I think we need to ANNOUNCE the incompatibility of this,
> >>and hopfuly give some upgrade paths for cloudstack users.
> >>
> >>
> >>(2013/03/05 7:24), Marcus Sorensen wrote:
> >>
> >>>I think this just requires an updated system vm (the virtio-serial
> >>>portion). I've played a bit with the old debian 2.6.32-5-686-bigmem
> >>>one and can't get the device nodes to show up, even though the
> >>>/boot/config shows that it has CONFIG_VIRTIO_CONSOLE=y. However, if I
> >>>try this with a CentOS 6.3 VM, on a CentOS 6.3 or Ubuntu 12.04 KVM
> >>>host it works. So I'm not sure what's being used for the ipv6 update,
> >>>but we can probably make one that works. We'll need to install qemu-ga
> >>>and start it within the systemvm as well.
> >>>
> >>>On Mon, Mar 4, 2013 at 12:41 PM, Edison Su  wrote:
> >>>
> 
> 
>   -Original Message-
> >From: Marcus Sorensen [mailto:shadow...@gmail.com]
> >Sent: Sunday, March 03, 2013 12:13 PM
> >To: 
> >cloudstack-dev@incubator.**apache.org
> >Subject: [DISCUSS] getting rid of KVM patchdisk
> >
> >For those who don't know (this probably doesn't matter, but...), when
> >KVM
> >brings up a system VM, it creates a 'patchdisk' on primary storage. This
> >patchdisk is used to pass along 1) the authorized_keys file and 2) a
> >'cmdline'
> >file that describes to the systemvm startup services all of the various
> >properties of the system vm.
> >
> >Example cmdline file:
> >
> >   template=domP type=secstorage host=172.17.10.10 port=8250 name=s-1-
> >VM
> >zone=1 pod=1 guid=s-1-VM
> >resource=com.cloud.storage.**resource.**NfsSecondaryStorageResource
> >instance=SecStorage sslcopy=true role=templateProcessor mtu=1500
> >eth2ip=192.168.100.170 eth2mask=255.255.255.0 gateway=192.168.100.1
> >public.network.device=eth2 eth0ip=169.254.1.46 eth0mask=255.255.0.0
> >eth1ip=172.17.10.150 eth1mask=255.255.255.0 mgmtcidr=172.17.10.0/24
> >localgw=172.17.10.1 private.network.device=eth1 eth3ip=172.17.10.192
> >eth3mask=255.255.255.0 storageip=172.17.10.192
> >storagenetmask=255.255.255.0 storagegateway=172.17.10.1
> >internaldns1=8.8.4.4 dns1=8.8.8.8
> >
> >This patch disk has been bugging me for awhile, as it creates a volume
> >that
> >isn't really tracked anywhere or known about in cloudstack's database.
> >Up
> >until recently these would just litter the KVM primary storages, but
> >there's
> >been some triage done to attempt to clean them up when the system vms
> >go away. It's not perfect. It also can be inefficient for certain
> >primary storage
> >types, for example if you end up creating a bunch of 10MB luns on a SAN
> >for
> >these.
> >
> >So my question goes to those who have been working on the system vm.
> >My first preference (aside from a full system vm redesign, perhaps
> >something that is controlled via an API) would be to copy these up to
> >the
> >system vm via SCP or something. But the cloud services start so early
> >on that
> >this isn't possible. Next would be to inject them into the system vm's
> >root
> >disk before starting the server, but if we're allowing people t

Re: [DISCUSS] Issue with cloudmonkey-4.1.0-0 on pypi

2013-06-23 Thread Prasanna Santhanam 
On Mon, Jun 24, 2013 at 09:17:16AM +0530, Rohit Yadav wrote:
> On Mon, Jun 24, 2013 at 2:20 AM, David Nalley  wrote:
> 
> > I've created this repo based on Rohit's work to preserve history.
> >
> >
> Great, thanks David. Maybe fix the repo description to "Apache CloudStack
> CLI" etc.

Just curious about how commit rights work on this one.

> 
> 
> > The repo is currently read only. I'd like several reviews of this repo
> > before I open it up for writes.
> >
> > https://git-wip-us.apache.org/repos/asf/cloudstack-cloudmonkey.git
> 
> 
> +1 review license, docs, any other thing that needs to be fixed.
> 

Will do.
-- 
Prasanna.,


Powered by BigRock.com

Re: git commit: Initial commit with LICENSE, NOTICE, and README.

2013-06-23 Thread Prasanna Santhanam 
On Sun, Jun 23, 2013 at 04:14:47PM -0500, Joe Brockmeier wrote:
> On Sun, Jun 23, 2013, at 04:01 PM, David Nalley wrote:
> > Uhhh - can we start with a fresh license and notice file.
> > There are clearly not some of the things mentioned in LICENSE/NOTICE
> > in this repo.
> 
> NOTICE should have been fine, but I corrected the LICENSE file. 
> 

Hmm - docs got its own repo too? I missed this. :/

-- 
Prasanna.,


Powered by BigRock.com

Re: [DISCUSS] getting rid of KVM patchdisk

2013-06-23 Thread Marcus Sorensen 
So what is the proposed fix? Just to find some way to warn when the
user isn't using the correct systemvm template (the new one required
for 4.2 has been based on Wheezy for awhile), other than nothing
working and them having to look in the logs?  This is probably a good
idea, we can perhaps have a shell script that goes through everything
on the template and makes sure everything is installed (e.g.
dnsmasq-utils, haproxy, virtio-console, and every other dependency).
It might be useful for those rolling their own system vms. It may be
tough to keep it up to date, but it's an interesting concept.

On Sun, Jun 23, 2013 at 9:35 PM, Hiroaki KAWAI  wrote:
> No I don't think we need to make such effort (sending emails) for devs,
> I think we should fix the code itself (and comments in the codes)
> because we're devs.
>
>
> (2013/06/24 12:20), Marcus Sorensen wrote:
>>
>> I personally thought it had been publicized pretty well on various threads
>> that there is a new system vm for master/4.2, but if you were unaware of
>> it, do you think more needs to be done to call it out and make it known to
>> the devs working on it?
>> On Jun 23, 2013 8:33 PM, "Hiroaki KAWAI"  wrote:
>>
>>> Current patch/systemvm/debian is based on debian squeeze,
>>> which kernel is 2.6.32-5-686-bigmem. In that system vm,
>>> cloud-early-config silently fails :
>>> /etc/init.d/cloud-early-**config: line 109: /dev/vport0p1: No such file
>>>
>>> or directory
>>> So I've upgraded to wheezy (which includes virtio-console.ko)
>>> # I pushed some patch for this.
>>>
>>> I think we need to ANNOUNCE the incompatibility of this,
>>> and hopfuly give some upgrade paths for cloudstack users.
>>>
>>>
>>> (2013/03/05 7:24), Marcus Sorensen wrote:
>>>
 I think this just requires an updated system vm (the virtio-serial
 portion). I've played a bit with the old debian 2.6.32-5-686-bigmem
 one and can't get the device nodes to show up, even though the
 /boot/config shows that it has CONFIG_VIRTIO_CONSOLE=y. However, if I
 try this with a CentOS 6.3 VM, on a CentOS 6.3 or Ubuntu 12.04 KVM
 host it works. So I'm not sure what's being used for the ipv6 update,
 but we can probably make one that works. We'll need to install qemu-ga
 and start it within the systemvm as well.

 On Mon, Mar 4, 2013 at 12:41 PM, Edison Su  wrote:

>
>
>   -Original Message-
>>
>> From: Marcus Sorensen [mailto:shadow...@gmail.com]
>> Sent: Sunday, March 03, 2013 12:13 PM
>> To:
>> cloudstack-dev@incubator.**apache.org
>>
>> Subject: [DISCUSS] getting rid of KVM patchdisk
>>
>> For those who don't know (this probably doesn't matter, but...), when
>> KVM
>> brings up a system VM, it creates a 'patchdisk' on primary storage.
>> This
>> patchdisk is used to pass along 1) the authorized_keys file and 2) a
>> 'cmdline'
>> file that describes to the systemvm startup services all of the
>> various
>> properties of the system vm.
>>
>> Example cmdline file:
>>
>>template=domP type=secstorage host=172.17.10.10 port=8250 name=s-1-
>> VM
>> zone=1 pod=1 guid=s-1-VM
>> resource=com.cloud.storage.**resource.**NfsSecondaryStorageResource
>>
>> instance=SecStorage sslcopy=true role=templateProcessor mtu=1500
>> eth2ip=192.168.100.170 eth2mask=255.255.255.0 gateway=192.168.100.1
>> public.network.device=eth2 eth0ip=169.254.1.46 eth0mask=255.255.0.0
>> eth1ip=172.17.10.150 eth1mask=255.255.255.0 mgmtcidr=172.17.10.0/24
>> localgw=172.17.10.1 private.network.device=eth1 eth3ip=172.17.10.192
>> eth3mask=255.255.255.0 storageip=172.17.10.192
>> storagenetmask=255.255.255.0 storagegateway=172.17.10.1
>> internaldns1=8.8.4.4 dns1=8.8.8.8
>>
>> This patch disk has been bugging me for awhile, as it creates a volume
>> that
>> isn't really tracked anywhere or known about in cloudstack's database.
>> Up
>> until recently these would just litter the KVM primary storages, but
>> there's
>> been some triage done to attempt to clean them up when the system vms
>> go away. It's not perfect. It also can be inefficient for certain
>> primary storage
>> types, for example if you end up creating a bunch of 10MB luns on a
>> SAN
>> for
>> these.
>>
>> So my question goes to those who have been working on the system vm.
>> My first preference (aside from a full system vm redesign, perhaps
>> something that is controlled via an API) would be to copy these up to
>> the
>> system vm via SCP or something. But the cloud services start so early
>> on that
>> this isn't possible. Next would be to inject them into the system vm's
>> root
>> disk before starting the server, but if we're allowing people to make
>> their
>> own system vms, can we count on the partitions being what we expect?
>> Also
>> I don't think this w

Be In Our CloudStack Videos: See You At Cloud Collab 2013

2013-06-23 Thread Jessica Tomechak 
If you’re attending the  CloudStack Collaboration Conference this week in
Santa Clara, you will see videographer Gregg Witkin shooting footage for
CloudStack videos. We’ll be getting content for both a “Top 10 Coolest
Clouds” video and also a “Conference Highlights” reel. Please note, this is
separate from any presentation videography which the conference center
might be capturing.

Feel free to approach Gregg if you see him in the halls. He’ll be the
cheerful guy toting a shoulder cam or setting up his tripod here and there
around the venue. Gregg might also tap you for your comments on the
conference or for an interview about your cloud.

There’s no obligation to participate, but we will appreciate it very much
if you feel you can do so.

Thanks,

Jessica Tomechak

Re: [DISCUSS] Issue with cloudmonkey-4.1.0-0 on pypi

2013-06-23 Thread David Nalley 
On Mon, Jun 24, 2013 at 12:40 AM, Prasanna Santhanam  wrote:
> On Mon, Jun 24, 2013 at 09:17:16AM +0530, Rohit Yadav wrote:
>> On Mon, Jun 24, 2013 at 2:20 AM, David Nalley  wrote:
>>
>> > I've created this repo based on Rohit's work to preserve history.
>> >
>> >
>> Great, thanks David. Maybe fix the repo description to "Apache CloudStack
>> CLI" etc.
>
> Just curious about how commit rights work on this one.
>

Any CloudStack committer has commits rights to this repo as well.

>>
>>
>> > The repo is currently read only. I'd like several reviews of this repo
>> > before I open it up for writes.
>> >
>> > https://git-wip-us.apache.org/repos/asf/cloudstack-cloudmonkey.git
>>
>>
>> +1 review license, docs, any other thing that needs to be fixed.
>>
>
> Will do.
> --

Mainly - I want to ensure that everyone agrees this is an accurate
representation of whats in /tools/cli
We can fix problems after we make it writable.

--David

Re: Review Request: Fix for CLOUDSTACK-2181: Scale down is allowed, which is not expected

2013-06-23 Thread ASF Subversion and Git Services 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11936/#review22317
---


Commit 1eb744fa1600f9400e407c6e3615da40b18758c1 in branch refs/heads/master 
from Harikrishna Patnala
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1eb744f ]

CLOUDSTACK-2181: Scale down is allowed when one resource(say cpu) is being 
scale up and other resource (say ram) is
 being scale down ;but not allowed when both resources are being scaledown
Signed off by : Nitin Mehta


- ASF Subversion and Git Services


On June 18, 2013, 2:38 p.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11936/
> ---
> 
> (Updated June 18, 2013, 2:38 p.m.)
> 
> 
> Review request for cloudstack and Nitin Mehta.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-2181: Scale down is allowed when one resource(say cpu) is being 
> scale up and other resource (say ram) is
>  being scale down ;but not allowed when both resources are being scaledown
> 
> 
> This addresses bug CLOUDSTACK-2181.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/vm/UserVmManagerImpl.java e8ea024 
> 
> Diff: https://reviews.apache.org/r/11936/diff/
> 
> 
> Testing
> ---
> 
> Tested locally
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request: Fix for CLOUDSTACK-2916, CLOUDSTACK-2457: validation for weight based configuration parameters

2013-06-23 Thread Nitin Mehta 


> On June 20, 2013, 10:12 a.m., Nitin Mehta wrote:
> > Ship It!

Please rebase

Nitins-MacBook-Air:cloudstack nitinmehta$ git apply 
../0001-CLOUDSTACK-2916-admin-is-not-able-to-login-through-U.patch 
error: patch failed: 
server/src/com/cloud/configuration/ConfigurationManagerImpl.java:336
error: server/src/com/cloud/configuration/ConfigurationManagerImpl.java: patch 
does not apply


- Nitin


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11989/#review22161
---


On June 20, 2013, 9:42 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11989/
> ---
> 
> (Updated June 20, 2013, 9:42 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Nitin Mehta.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-2916: admin is not able to login through UI after setting GP 
> "cluster.cpu.allocated.capacity.notificationthreshold" to some string 
> CLOUDSTACK-2457:  No check for input values,special character,-ive values can 
> be assigne to GLobal parameter 
> "cluster.cpu.allocated.capacity.disablethreshold"
> 
> Added validation for float values and checking limit for weight based 
> parameters by creating a set of parameters.
> 
> 
> This addresses bugs CLOUDSTACK-2457 and CLOUDSTACK-2916.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 131d340 
> 
> Diff: https://reviews.apache.org/r/11989/diff/
> 
> 
> Testing
> ---
> 
> Tested locally
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>