Re: [DISCUSS] 4.3.1

[Daan Hoogland]

David, this is very depending on the amount/nature of the upgrade code
from 4.3.0 to 4.3.1 In the best case no extra upgrade code has to be
written and the 4.3.0 to 4.4.0 code can be used. In the worst case a
full set of conditional schema changes has to be created. I am not
pessimistic, totally against my nature.

regards,
Daan

On Thu, Jun 12, 2014 at 4:57 PM, David Nalley  wrote:
> And just as important - figuring out an upgrade strategy from 4.3.1 to 4.4.0
>
> --David
>
> On Thu, Jun 12, 2014 at 10:24 AM, Daan Hoogland  
> wrote:
>> not a cherry-pick but a upgrade data thingy:
>>
>> private void updateVlanUris(Connection conn) from Upgrade430to440.java
>> should be implemented in Upgrade430to431.java (to be created) as well.
>>
>> On Thu, Jun 12, 2014 at 4:17 PM, sebgoa  wrote:
>>> While we are talking about 4.4
>>>
>>> I am game to RM a 4.3.1 , there has been several bug fixes since 4.3.0.
>>>
>>> Anybody interested, any suggestions of what would still need to be cherry 
>>> picked ?
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.3
>>>
>>> -Sebastien
>>
>>
>>
>> --
>> Daan



-- 
Daan

Re: [ACS44] CLOUDSTACK-6908: Enable IPv6 in sysctl when only necessary

[Daan Hoogland]

On Sat, Jun 14, 2014 at 1:08 AM, Sheng Yang  wrote:
> 60e46293234cccea5d2bd31588123e65af3e9bad


is in

-- 
Daan

[ACS44] CLOUDSTACK-6908: Enable IPv6 in sysctl when only necessary

[Sheng Yang]

Hi Daan,

Please cherry-pick following commit from 4.4-forward.

Thanks!

commit 60e46293234cccea5d2bd31588123e65af3e9bad
Author: Sheng Yang 
Date:   Fri Jun 13 11:05:35 2014 -0700

CLOUDSTACK-6908: Enable IPv6 in sysctl when only necessary

This new way would only enable IPv6 when VR is created in IPv6 shared
network.
Otherwise IPv6 sysctl options remain disable.

--Sheng

CloudStack-3831

[Matt Spurlin]

I have created a patch for CloudStack-3831, but unfortunately I am
having an issue getting it submitted to the review board. Upon
submission I get the following error:

Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /r/new/.


Is there another way I can submit this to the review board?

Re: DevCloud replacement

[Rohit Yadav]

Caching of templates would be great, looking forward to your work on rest
of the designs.

Cheers.


On Sat, Jun 14, 2014 at 12:35 AM, Ian Duffy  wrote:

> Awesome!
>
> I'm still tweaking things here and there. For whatever reason my internet
> connection to S3 is very poor so I'm insuring that caching of templates on
> the host via vagrant-cachier works 100%.
>
> Will do out more in-depth documentation over the next 2 weeks. Will
> explain what makes up the boxes and how all the projects tie into each
> other.
>
> Still need to deliver on the two other designs 2
> http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/imduffy15/5662278724616192
>
>
> On 13 June 2014 20:02, Rohit Yadav  wrote:
>
>> Thanks for your work Ian, it's up and running, and I finally have a Xen
>> vm/box to play with.
>>
>> Cheers.
>>
>>
>> On Fri, Jun 13, 2014 at 11:51 PM, Ian Duffy  wrote:
>>
>>> Hi Rohit,
>>>
>>> Thank you for the PR :) was meaning to add a section on the vagrant
>>> setup.
>>>
>>> I've recently extended some of it to use vagrant-cachier for caching the
>>> systemvm templates.
>>>
>>>
>>> On 13 June 2014 19:05, Rohit Yadav  wrote:
>>>
 I've fixed README: https://github.com/imduffy15/GSoC-2014/pull/1

 I installed two vagrant plugins and now it has started to work :) Still
 under progress.

 Cheers.



 On Fri, Jun 13, 2014 at 11:21 PM, Rohit Yadav 
 wrote:

> Hi Ian,
>
> I tried to launch using vagrant up and getting following errors
> related to librarian_chef and omnibus. I just followed the README file -
> cloned your repo, updated submodules (so they are cloned too) and did
> vagrant up.
>
> Before opening issue on JIRA, I thought I share it here. Here's the
> full log;
>
> $ vagrant up
>
> [21:48:22]
>
> Bringing machine 'management' up with 'virtualbox' provider...
>
> Bringing machine 'xenserver' up with 'virtualbox' provider...
>
> ==> management: Box 'chef/centos-6.5' could not be found. Attempting
> to find and install...
>
> management: Box Provider: virtualbox
>
> management: Box Version: >= 0
>
> ==> management: Loading metadata for box 'chef/centos-6.5'
>
> management: URL: https://vagrantcloud.com/chef/centos-6.5
>
> ==> management: Adding box 'chef/centos-6.5' (v1.0.0) for provider:
> virtualbox
>
> management: Downloading:
> https://vagrantcloud.com/chef/centos-6.5/version/1/provider/virtualbox.box
>
> ==> management: Successfully added box 'chef/centos-6.5' (v1.0.0) for
> 'virtualbox'!
>
> There are errors in the configuration of this machine. Please fix
>
> the following errors and try again:
>
> Vagrant:
>
> * Unknown configuration section 'librarian_chef'.
>
> * Unknown configuration section 'omnibus'.
>
>
>
>
> On Fri, Jun 13, 2014 at 9:41 PM, Rohit Yadav 
> wrote:
>
>> On Fri, Jun 13, 2014 at 9:25 PM, Daan Hoogland <
>> daan.hoogl...@gmail.com> wrote:
>>
>>> Thanks Sebastien and of course Ian,
>>>
>>> I will try. BUT i think the reason is that xcp is not well supported
>>> and devcloud is not based on xenserver but on xcp or even a vanilla
>>> (debian/ubuntu?) xen. So will we continue on Ians path or go back and
>>> fix devcloud?
>>>
>>
>> I think there is no point in supporting XCP, so we should continue
>> with Ian's path and start using/testing ACS with xenserver ( or 
>> xenproject).
>>
>>  Thanks Ian and Sebastien, trying it out now.
>>
>> The ttylinux image is also accessible here:
>> http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd
>>
>> Cheers.
>>
>>
>>>
>>> On Fri, Jun 13, 2014 at 5:36 PM, sebgoa  wrote:
>>> > Hi folks,
>>> >
>>> > As you know I love Devcloud, but it has its pains and lately it
>>> got broken in 4.3, and I don't think it works with 4.4.
>>> >
>>> > So I encourage you to check out:
>>> >
>>> > https://github.com/imduffy15/GSoC-2014
>>> >
>>> > This works out of the box.
>>> >
>>> > It is from Ian , it uses Vagrant boxes that are available in the
>>> vagrant cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a
>>> xenserver box for the hypervisor.
>>> > You then build locally, 3306 is forwarded localhost, so it looks
>>> like your db is local. NAT routing is setup nicely.
>>> > Devcloud cfg file used .
>>> >
>>> > You start bhaissab ttylinux image.
>>> >
>>> > It uses Chef recipes ...
>>> >
>>> > It works out of the box.
>>> >
>>> > Enjoy the week-end,
>>> >
>>> > -Sebastien
>>>
>>>
>>>
>>> --
>>> Daan
>>>
>>
>>
>

>>>
>>
>

Re: DevCloud replacement

[Ian Duffy]

Awesome!

I'm still tweaking things here and there. For whatever reason my internet
connection to S3 is very poor so I'm insuring that caching of templates on
the host via vagrant-cachier works 100%.

Will do out more in-depth documentation over the next 2 weeks. Will explain
what makes up the boxes and how all the projects tie into each other.

Still need to deliver on the two other designs 2
http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/imduffy15/5662278724616192


On 13 June 2014 20:02, Rohit Yadav  wrote:

> Thanks for your work Ian, it's up and running, and I finally have a Xen
> vm/box to play with.
>
> Cheers.
>
>
> On Fri, Jun 13, 2014 at 11:51 PM, Ian Duffy  wrote:
>
>> Hi Rohit,
>>
>> Thank you for the PR :) was meaning to add a section on the vagrant setup.
>>
>> I've recently extended some of it to use vagrant-cachier for caching the
>> systemvm templates.
>>
>>
>> On 13 June 2014 19:05, Rohit Yadav  wrote:
>>
>>> I've fixed README: https://github.com/imduffy15/GSoC-2014/pull/1
>>>
>>> I installed two vagrant plugins and now it has started to work :) Still
>>> under progress.
>>>
>>> Cheers.
>>>
>>>
>>>
>>> On Fri, Jun 13, 2014 at 11:21 PM, Rohit Yadav 
>>> wrote:
>>>
 Hi Ian,

 I tried to launch using vagrant up and getting following errors related
 to librarian_chef and omnibus. I just followed the README file - cloned
 your repo, updated submodules (so they are cloned too) and did vagrant up.

 Before opening issue on JIRA, I thought I share it here. Here's the
 full log;

 $ vagrant up
 [21:48:22]

 Bringing machine 'management' up with 'virtualbox' provider...

 Bringing machine 'xenserver' up with 'virtualbox' provider...

 ==> management: Box 'chef/centos-6.5' could not be found. Attempting to
 find and install...

 management: Box Provider: virtualbox

 management: Box Version: >= 0

 ==> management: Loading metadata for box 'chef/centos-6.5'

 management: URL: https://vagrantcloud.com/chef/centos-6.5

 ==> management: Adding box 'chef/centos-6.5' (v1.0.0) for provider:
 virtualbox

 management: Downloading:
 https://vagrantcloud.com/chef/centos-6.5/version/1/provider/virtualbox.box

 ==> management: Successfully added box 'chef/centos-6.5' (v1.0.0) for
 'virtualbox'!

 There are errors in the configuration of this machine. Please fix

 the following errors and try again:

 Vagrant:

 * Unknown configuration section 'librarian_chef'.

 * Unknown configuration section 'omnibus'.




 On Fri, Jun 13, 2014 at 9:41 PM, Rohit Yadav 
 wrote:

> On Fri, Jun 13, 2014 at 9:25 PM, Daan Hoogland <
> daan.hoogl...@gmail.com> wrote:
>
>> Thanks Sebastien and of course Ian,
>>
>> I will try. BUT i think the reason is that xcp is not well supported
>> and devcloud is not based on xenserver but on xcp or even a vanilla
>> (debian/ubuntu?) xen. So will we continue on Ians path or go back and
>> fix devcloud?
>>
>
> I think there is no point in supporting XCP, so we should continue
> with Ian's path and start using/testing ACS with xenserver ( or 
> xenproject).
>
>  Thanks Ian and Sebastien, trying it out now.
>
> The ttylinux image is also accessible here:
> http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd
>
> Cheers.
>
>
>>
>> On Fri, Jun 13, 2014 at 5:36 PM, sebgoa  wrote:
>> > Hi folks,
>> >
>> > As you know I love Devcloud, but it has its pains and lately it got
>> broken in 4.3, and I don't think it works with 4.4.
>> >
>> > So I encourage you to check out:
>> >
>> > https://github.com/imduffy15/GSoC-2014
>> >
>> > This works out of the box.
>> >
>> > It is from Ian , it uses Vagrant boxes that are available in the
>> vagrant cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a
>> xenserver box for the hypervisor.
>> > You then build locally, 3306 is forwarded localhost, so it looks
>> like your db is local. NAT routing is setup nicely.
>> > Devcloud cfg file used .
>> >
>> > You start bhaissab ttylinux image.
>> >
>> > It uses Chef recipes …
>> >
>> > It works out of the box.
>> >
>> > Enjoy the week-end,
>> >
>> > -Sebastien
>>
>>
>>
>> --
>> Daan
>>
>
>

>>>
>>
>

Re: DevCloud replacement

[Rohit Yadav]

Thanks for your work Ian, it's up and running, and I finally have a Xen
vm/box to play with.

Cheers.


On Fri, Jun 13, 2014 at 11:51 PM, Ian Duffy  wrote:

> Hi Rohit,
>
> Thank you for the PR :) was meaning to add a section on the vagrant setup.
>
> I've recently extended some of it to use vagrant-cachier for caching the
> systemvm templates.
>
>
> On 13 June 2014 19:05, Rohit Yadav  wrote:
>
>> I've fixed README: https://github.com/imduffy15/GSoC-2014/pull/1
>>
>> I installed two vagrant plugins and now it has started to work :) Still
>> under progress.
>>
>> Cheers.
>>
>>
>>
>> On Fri, Jun 13, 2014 at 11:21 PM, Rohit Yadav 
>> wrote:
>>
>>> Hi Ian,
>>>
>>> I tried to launch using vagrant up and getting following errors related
>>> to librarian_chef and omnibus. I just followed the README file - cloned
>>> your repo, updated submodules (so they are cloned too) and did vagrant up.
>>>
>>> Before opening issue on JIRA, I thought I share it here. Here's the full
>>> log;
>>>
>>> $ vagrant up
>>> [21:48:22]
>>>
>>> Bringing machine 'management' up with 'virtualbox' provider...
>>>
>>> Bringing machine 'xenserver' up with 'virtualbox' provider...
>>>
>>> ==> management: Box 'chef/centos-6.5' could not be found. Attempting to
>>> find and install...
>>>
>>> management: Box Provider: virtualbox
>>>
>>> management: Box Version: >= 0
>>>
>>> ==> management: Loading metadata for box 'chef/centos-6.5'
>>>
>>> management: URL: https://vagrantcloud.com/chef/centos-6.5
>>>
>>> ==> management: Adding box 'chef/centos-6.5' (v1.0.0) for provider:
>>> virtualbox
>>>
>>> management: Downloading:
>>> https://vagrantcloud.com/chef/centos-6.5/version/1/provider/virtualbox.box
>>>
>>> ==> management: Successfully added box 'chef/centos-6.5' (v1.0.0) for
>>> 'virtualbox'!
>>>
>>> There are errors in the configuration of this machine. Please fix
>>>
>>> the following errors and try again:
>>>
>>> Vagrant:
>>>
>>> * Unknown configuration section 'librarian_chef'.
>>>
>>> * Unknown configuration section 'omnibus'.
>>>
>>>
>>>
>>>
>>> On Fri, Jun 13, 2014 at 9:41 PM, Rohit Yadav 
>>> wrote:
>>>
 On Fri, Jun 13, 2014 at 9:25 PM, Daan Hoogland >>> > wrote:

> Thanks Sebastien and of course Ian,
>
> I will try. BUT i think the reason is that xcp is not well supported
> and devcloud is not based on xenserver but on xcp or even a vanilla
> (debian/ubuntu?) xen. So will we continue on Ians path or go back and
> fix devcloud?
>

 I think there is no point in supporting XCP, so we should continue with
 Ian's path and start using/testing ACS with xenserver ( or xenproject).

  Thanks Ian and Sebastien, trying it out now.

 The ttylinux image is also accessible here:
 http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd

 Cheers.


>
> On Fri, Jun 13, 2014 at 5:36 PM, sebgoa  wrote:
> > Hi folks,
> >
> > As you know I love Devcloud, but it has its pains and lately it got
> broken in 4.3, and I don't think it works with 4.4.
> >
> > So I encourage you to check out:
> >
> > https://github.com/imduffy15/GSoC-2014
> >
> > This works out of the box.
> >
> > It is from Ian , it uses Vagrant boxes that are available in the
> vagrant cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a
> xenserver box for the hypervisor.
> > You then build locally, 3306 is forwarded localhost, so it looks
> like your db is local. NAT routing is setup nicely.
> > Devcloud cfg file used .
> >
> > You start bhaissab ttylinux image.
> >
> > It uses Chef recipes ...
> >
> > It works out of the box.
> >
> > Enjoy the week-end,
> >
> > -Sebastien
>
>
>
> --
> Daan
>


>>>
>>
>

Unable to start primary and secondary storage instances

[Elapavuluri, Jaya]

Hello,

I am trying to run the cloudstack (4.4), where the following are warnings shown,

Unable to acquire lock on storage vm
WARN  [o.a.c.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-23287615) 
Exception while trying to start secondary storage vm
java.lang.RuntimeException: Job failed due to exception Resource [Host:1] is 
unreachable: Host 1: Unable to start instance due to Unable to acquire lock on 
VMTemplateStoragePool: 66
   at 
com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:114)
   at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
   at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
   at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
   at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
   at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
   at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
   at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
   at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
   at java.util.concurrent.FutureTask.run(FutureTask.java:262)
   at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
   at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
   at java.lang.Thread.run(Thread.java:745)
INFO  [o.a.c.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-23287615) Unable 
to start secondary storage vm for standby capacity, secStorageVm vm Id : 57, 
will recycle it and start a new one
INFO  [o.a.c.s.PremiumSecondaryStorageManagerImpl] (secstorage-1:ctx-23287615) 
Primary secondary storage is not even started, wait until next turn
INFO  [o.a.c.f.j.i.AsyncJobMonitor] (Work-Job-Executor-25:ctx-8555714b 
job-276/job-301) Remove job-301


Could some one help me on this.

Re: DevCloud replacement

[Rohit Yadav]

On Fri, Jun 13, 2014 at 11:54 PM, Ian Duffy  wrote:

> Just out of interest.
>
> Is there any reason we don't use devcloud.sql to modify the service
> offerings and disk offerings to use local storage?
>
>
I think we should do it, I used to do it myself (manually though).

I was also thinking to change couple of default CloudStack global settings.
For example, the local storage for systemvms to true -- these days any host
would consist of 100+GBs primary storage. In previous decades/years, I
could understand why people had dedicated secondary storages but now a
typical host is capable of having terabytes of storage therefore we should
allow systemvms to run on local storage by default among other things.

Also, I think most of us have been setting them up (which is a pain)
everytime we boot up ACS on a freshly deployed database.

Regards.


>
> On 13 June 2014 19:21, Ian Duffy  wrote:
>
> > Hi Rohit,
> >
> > Thank you for the PR :) was meaning to add a section on the vagrant
> setup.
> >
> > I've recently extended some of it to use vagrant-cachier for caching the
> > systemvm templates.
> >
> >
> > On 13 June 2014 19:05, Rohit Yadav  wrote:
> >
> >> I've fixed README: https://github.com/imduffy15/GSoC-2014/pull/1
> >>
> >> I installed two vagrant plugins and now it has started to work :) Still
> >> under progress.
> >>
> >> Cheers.
> >>
> >>
> >>
> >> On Fri, Jun 13, 2014 at 11:21 PM, Rohit Yadav 
> >> wrote:
> >>
> >>> Hi Ian,
> >>>
> >>> I tried to launch using vagrant up and getting following errors related
> >>> to librarian_chef and omnibus. I just followed the README file - cloned
> >>> your repo, updated submodules (so they are cloned too) and did vagrant
> up.
> >>>
> >>> Before opening issue on JIRA, I thought I share it here. Here's the
> full
> >>> log;
> >>>
> >>> $ vagrant up
> >>> [21:48:22]
> >>>
> >>> Bringing machine 'management' up with 'virtualbox' provider...
> >>>
> >>> Bringing machine 'xenserver' up with 'virtualbox' provider...
> >>>
> >>> ==> management: Box 'chef/centos-6.5' could not be found. Attempting to
> >>> find and install...
> >>>
> >>> management: Box Provider: virtualbox
> >>>
> >>> management: Box Version: >= 0
> >>>
> >>> ==> management: Loading metadata for box 'chef/centos-6.5'
> >>>
> >>> management: URL: https://vagrantcloud.com/chef/centos-6.5
> >>>
> >>> ==> management: Adding box 'chef/centos-6.5' (v1.0.0) for provider:
> >>> virtualbox
> >>>
> >>> management: Downloading:
> >>>
> https://vagrantcloud.com/chef/centos-6.5/version/1/provider/virtualbox.box
> >>>
> >>> ==> management: Successfully added box 'chef/centos-6.5' (v1.0.0) for
> >>> 'virtualbox'!
> >>>
> >>> There are errors in the configuration of this machine. Please fix
> >>>
> >>> the following errors and try again:
> >>>
> >>> Vagrant:
> >>>
> >>> * Unknown configuration section 'librarian_chef'.
> >>>
> >>> * Unknown configuration section 'omnibus'.
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, Jun 13, 2014 at 9:41 PM, Rohit Yadav 
> >>> wrote:
> >>>
>  On Fri, Jun 13, 2014 at 9:25 PM, Daan Hoogland <
> daan.hoogl...@gmail.com
>  > wrote:
> 
> > Thanks Sebastien and of course Ian,
> >
> > I will try. BUT i think the reason is that xcp is not well supported
> > and devcloud is not based on xenserver but on xcp or even a vanilla
> > (debian/ubuntu?) xen. So will we continue on Ians path or go back and
> > fix devcloud?
> >
> 
>  I think there is no point in supporting XCP, so we should continue
> with
>  Ian's path and start using/testing ACS with xenserver ( or
> xenproject).
> 
>   Thanks Ian and Sebastien, trying it out now.
> 
>  The ttylinux image is also accessible here:
>  http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd
> 
>  Cheers.
> 
> 
> >
> > On Fri, Jun 13, 2014 at 5:36 PM, sebgoa  wrote:
> > > Hi folks,
> > >
> > > As you know I love Devcloud, but it has its pains and lately it got
> > broken in 4.3, and I don't think it works with 4.4.
> > >
> > > So I encourage you to check out:
> > >
> > > https://github.com/imduffy15/GSoC-2014
> > >
> > > This works out of the box.
> > >
> > > It is from Ian , it uses Vagrant boxes that are available in the
> > vagrant cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses
> a
> > xenserver box for the hypervisor.
> > > You then build locally, 3306 is forwarded localhost, so it looks
> > like your db is local. NAT routing is setup nicely.
> > > Devcloud cfg file used .
> > >
> > > You start bhaissab ttylinux image.
> > >
> > > It uses Chef recipes ...
> > >
> > > It works out of the box.
> > >
> > > Enjoy the week-end,
> > >
> > > -Sebastien
> >
> >
> >
> > --
> > Daan
> >
> 
> 
> >>>
> >>
> >
>

Re: DevCloud replacement

[Ian Duffy]

Just out of interest.

Is there any reason we don't use devcloud.sql to modify the service
offerings and disk offerings to use local storage?


On 13 June 2014 19:21, Ian Duffy  wrote:

> Hi Rohit,
>
> Thank you for the PR :) was meaning to add a section on the vagrant setup.
>
> I've recently extended some of it to use vagrant-cachier for caching the
> systemvm templates.
>
>
> On 13 June 2014 19:05, Rohit Yadav  wrote:
>
>> I've fixed README: https://github.com/imduffy15/GSoC-2014/pull/1
>>
>> I installed two vagrant plugins and now it has started to work :) Still
>> under progress.
>>
>> Cheers.
>>
>>
>>
>> On Fri, Jun 13, 2014 at 11:21 PM, Rohit Yadav 
>> wrote:
>>
>>> Hi Ian,
>>>
>>> I tried to launch using vagrant up and getting following errors related
>>> to librarian_chef and omnibus. I just followed the README file - cloned
>>> your repo, updated submodules (so they are cloned too) and did vagrant up.
>>>
>>> Before opening issue on JIRA, I thought I share it here. Here's the full
>>> log;
>>>
>>> $ vagrant up
>>> [21:48:22]
>>>
>>> Bringing machine 'management' up with 'virtualbox' provider...
>>>
>>> Bringing machine 'xenserver' up with 'virtualbox' provider...
>>>
>>> ==> management: Box 'chef/centos-6.5' could not be found. Attempting to
>>> find and install...
>>>
>>> management: Box Provider: virtualbox
>>>
>>> management: Box Version: >= 0
>>>
>>> ==> management: Loading metadata for box 'chef/centos-6.5'
>>>
>>> management: URL: https://vagrantcloud.com/chef/centos-6.5
>>>
>>> ==> management: Adding box 'chef/centos-6.5' (v1.0.0) for provider:
>>> virtualbox
>>>
>>> management: Downloading:
>>> https://vagrantcloud.com/chef/centos-6.5/version/1/provider/virtualbox.box
>>>
>>> ==> management: Successfully added box 'chef/centos-6.5' (v1.0.0) for
>>> 'virtualbox'!
>>>
>>> There are errors in the configuration of this machine. Please fix
>>>
>>> the following errors and try again:
>>>
>>> Vagrant:
>>>
>>> * Unknown configuration section 'librarian_chef'.
>>>
>>> * Unknown configuration section 'omnibus'.
>>>
>>>
>>>
>>>
>>> On Fri, Jun 13, 2014 at 9:41 PM, Rohit Yadav 
>>> wrote:
>>>
 On Fri, Jun 13, 2014 at 9:25 PM, Daan Hoogland >>> > wrote:

> Thanks Sebastien and of course Ian,
>
> I will try. BUT i think the reason is that xcp is not well supported
> and devcloud is not based on xenserver but on xcp or even a vanilla
> (debian/ubuntu?) xen. So will we continue on Ians path or go back and
> fix devcloud?
>

 I think there is no point in supporting XCP, so we should continue with
 Ian's path and start using/testing ACS with xenserver ( or xenproject).

  Thanks Ian and Sebastien, trying it out now.

 The ttylinux image is also accessible here:
 http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd

 Cheers.


>
> On Fri, Jun 13, 2014 at 5:36 PM, sebgoa  wrote:
> > Hi folks,
> >
> > As you know I love Devcloud, but it has its pains and lately it got
> broken in 4.3, and I don't think it works with 4.4.
> >
> > So I encourage you to check out:
> >
> > https://github.com/imduffy15/GSoC-2014
> >
> > This works out of the box.
> >
> > It is from Ian , it uses Vagrant boxes that are available in the
> vagrant cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a
> xenserver box for the hypervisor.
> > You then build locally, 3306 is forwarded localhost, so it looks
> like your db is local. NAT routing is setup nicely.
> > Devcloud cfg file used .
> >
> > You start bhaissab ttylinux image.
> >
> > It uses Chef recipes …
> >
> > It works out of the box.
> >
> > Enjoy the week-end,
> >
> > -Sebastien
>
>
>
> --
> Daan
>


>>>
>>
>

Re: DevCloud replacement

[Ian Duffy]

Hi Rohit,

Thank you for the PR :) was meaning to add a section on the vagrant setup.

I've recently extended some of it to use vagrant-cachier for caching the
systemvm templates.


On 13 June 2014 19:05, Rohit Yadav  wrote:

> I've fixed README: https://github.com/imduffy15/GSoC-2014/pull/1
>
> I installed two vagrant plugins and now it has started to work :) Still
> under progress.
>
> Cheers.
>
>
>
> On Fri, Jun 13, 2014 at 11:21 PM, Rohit Yadav  wrote:
>
>> Hi Ian,
>>
>> I tried to launch using vagrant up and getting following errors related
>> to librarian_chef and omnibus. I just followed the README file - cloned
>> your repo, updated submodules (so they are cloned too) and did vagrant up.
>>
>> Before opening issue on JIRA, I thought I share it here. Here's the full
>> log;
>>
>> $ vagrant up
>>   [21:48:22]
>>
>> Bringing machine 'management' up with 'virtualbox' provider...
>>
>> Bringing machine 'xenserver' up with 'virtualbox' provider...
>>
>> ==> management: Box 'chef/centos-6.5' could not be found. Attempting to
>> find and install...
>>
>> management: Box Provider: virtualbox
>>
>> management: Box Version: >= 0
>>
>> ==> management: Loading metadata for box 'chef/centos-6.5'
>>
>> management: URL: https://vagrantcloud.com/chef/centos-6.5
>>
>> ==> management: Adding box 'chef/centos-6.5' (v1.0.0) for provider:
>> virtualbox
>>
>> management: Downloading:
>> https://vagrantcloud.com/chef/centos-6.5/version/1/provider/virtualbox.box
>>
>> ==> management: Successfully added box 'chef/centos-6.5' (v1.0.0) for
>> 'virtualbox'!
>>
>> There are errors in the configuration of this machine. Please fix
>>
>> the following errors and try again:
>>
>> Vagrant:
>>
>> * Unknown configuration section 'librarian_chef'.
>>
>> * Unknown configuration section 'omnibus'.
>>
>>
>>
>>
>> On Fri, Jun 13, 2014 at 9:41 PM, Rohit Yadav  wrote:
>>
>>> On Fri, Jun 13, 2014 at 9:25 PM, Daan Hoogland 
>>> wrote:
>>>
 Thanks Sebastien and of course Ian,

 I will try. BUT i think the reason is that xcp is not well supported
 and devcloud is not based on xenserver but on xcp or even a vanilla
 (debian/ubuntu?) xen. So will we continue on Ians path or go back and
 fix devcloud?

>>>
>>> I think there is no point in supporting XCP, so we should continue with
>>> Ian's path and start using/testing ACS with xenserver ( or xenproject).
>>>
>>>  Thanks Ian and Sebastien, trying it out now.
>>>
>>> The ttylinux image is also accessible here:
>>> http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd
>>>
>>> Cheers.
>>>
>>>

 On Fri, Jun 13, 2014 at 5:36 PM, sebgoa  wrote:
 > Hi folks,
 >
 > As you know I love Devcloud, but it has its pains and lately it got
 broken in 4.3, and I don't think it works with 4.4.
 >
 > So I encourage you to check out:
 >
 > https://github.com/imduffy15/GSoC-2014
 >
 > This works out of the box.
 >
 > It is from Ian , it uses Vagrant boxes that are available in the
 vagrant cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a
 xenserver box for the hypervisor.
 > You then build locally, 3306 is forwarded localhost, so it looks like
 your db is local. NAT routing is setup nicely.
 > Devcloud cfg file used .
 >
 > You start bhaissab ttylinux image.
 >
 > It uses Chef recipes …
 >
 > It works out of the box.
 >
 > Enjoy the week-end,
 >
 > -Sebastien



 --
 Daan

>>>
>>>
>>
>

Re: DevCloud replacement

[Rohit Yadav]

I've fixed README: https://github.com/imduffy15/GSoC-2014/pull/1

I installed two vagrant plugins and now it has started to work :) Still
under progress.

Cheers.


On Fri, Jun 13, 2014 at 11:21 PM, Rohit Yadav  wrote:

> Hi Ian,
>
> I tried to launch using vagrant up and getting following errors related to
> librarian_chef and omnibus. I just followed the README file - cloned your
> repo, updated submodules (so they are cloned too) and did vagrant up.
>
> Before opening issue on JIRA, I thought I share it here. Here's the full
> log;
>
> $ vagrant up
>   [21:48:22]
>
> Bringing machine 'management' up with 'virtualbox' provider...
>
> Bringing machine 'xenserver' up with 'virtualbox' provider...
>
> ==> management: Box 'chef/centos-6.5' could not be found. Attempting to
> find and install...
>
> management: Box Provider: virtualbox
>
> management: Box Version: >= 0
>
> ==> management: Loading metadata for box 'chef/centos-6.5'
>
> management: URL: https://vagrantcloud.com/chef/centos-6.5
>
> ==> management: Adding box 'chef/centos-6.5' (v1.0.0) for provider:
> virtualbox
>
> management: Downloading:
> https://vagrantcloud.com/chef/centos-6.5/version/1/provider/virtualbox.box
>
> ==> management: Successfully added box 'chef/centos-6.5' (v1.0.0) for
> 'virtualbox'!
>
> There are errors in the configuration of this machine. Please fix
>
> the following errors and try again:
>
> Vagrant:
>
> * Unknown configuration section 'librarian_chef'.
>
> * Unknown configuration section 'omnibus'.
>
>
>
>
> On Fri, Jun 13, 2014 at 9:41 PM, Rohit Yadav  wrote:
>
>> On Fri, Jun 13, 2014 at 9:25 PM, Daan Hoogland 
>> wrote:
>>
>>> Thanks Sebastien and of course Ian,
>>>
>>> I will try. BUT i think the reason is that xcp is not well supported
>>> and devcloud is not based on xenserver but on xcp or even a vanilla
>>> (debian/ubuntu?) xen. So will we continue on Ians path or go back and
>>> fix devcloud?
>>>
>>
>> I think there is no point in supporting XCP, so we should continue with
>> Ian's path and start using/testing ACS with xenserver ( or xenproject).
>>
>>  Thanks Ian and Sebastien, trying it out now.
>>
>> The ttylinux image is also accessible here:
>> http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd
>>
>> Cheers.
>>
>>
>>>
>>> On Fri, Jun 13, 2014 at 5:36 PM, sebgoa  wrote:
>>> > Hi folks,
>>> >
>>> > As you know I love Devcloud, but it has its pains and lately it got
>>> broken in 4.3, and I don't think it works with 4.4.
>>> >
>>> > So I encourage you to check out:
>>> >
>>> > https://github.com/imduffy15/GSoC-2014
>>> >
>>> > This works out of the box.
>>> >
>>> > It is from Ian , it uses Vagrant boxes that are available in the
>>> vagrant cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a
>>> xenserver box for the hypervisor.
>>> > You then build locally, 3306 is forwarded localhost, so it looks like
>>> your db is local. NAT routing is setup nicely.
>>> > Devcloud cfg file used .
>>> >
>>> > You start bhaissab ttylinux image.
>>> >
>>> > It uses Chef recipes ...
>>> >
>>> > It works out of the box.
>>> >
>>> > Enjoy the week-end,
>>> >
>>> > -Sebastien
>>>
>>>
>>>
>>> --
>>> Daan
>>>
>>
>>
>

Re: DevCloud replacement

[Rohit Yadav]

Hi Ian,

I tried to launch using vagrant up and getting following errors related to
librarian_chef and omnibus. I just followed the README file - cloned your
repo, updated submodules (so they are cloned too) and did vagrant up.

Before opening issue on JIRA, I thought I share it here. Here's the full
log;

$ vagrant up
[21:48:22]

Bringing machine 'management' up with 'virtualbox' provider...

Bringing machine 'xenserver' up with 'virtualbox' provider...

==> management: Box 'chef/centos-6.5' could not be found. Attempting to
find and install...

management: Box Provider: virtualbox

management: Box Version: >= 0

==> management: Loading metadata for box 'chef/centos-6.5'

management: URL: https://vagrantcloud.com/chef/centos-6.5

==> management: Adding box 'chef/centos-6.5' (v1.0.0) for provider:
virtualbox

management: Downloading:
https://vagrantcloud.com/chef/centos-6.5/version/1/provider/virtualbox.box

==> management: Successfully added box 'chef/centos-6.5' (v1.0.0) for
'virtualbox'!

There are errors in the configuration of this machine. Please fix

the following errors and try again:

Vagrant:

* Unknown configuration section 'librarian_chef'.

* Unknown configuration section 'omnibus'.




On Fri, Jun 13, 2014 at 9:41 PM, Rohit Yadav  wrote:

> On Fri, Jun 13, 2014 at 9:25 PM, Daan Hoogland 
> wrote:
>
>> Thanks Sebastien and of course Ian,
>>
>> I will try. BUT i think the reason is that xcp is not well supported
>> and devcloud is not based on xenserver but on xcp or even a vanilla
>> (debian/ubuntu?) xen. So will we continue on Ians path or go back and
>> fix devcloud?
>>
>
> I think there is no point in supporting XCP, so we should continue with
> Ian's path and start using/testing ACS with xenserver ( or xenproject).
>
>  Thanks Ian and Sebastien, trying it out now.
>
> The ttylinux image is also accessible here:
> http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd
>
> Cheers.
>
>
>>
>> On Fri, Jun 13, 2014 at 5:36 PM, sebgoa  wrote:
>> > Hi folks,
>> >
>> > As you know I love Devcloud, but it has its pains and lately it got
>> broken in 4.3, and I don't think it works with 4.4.
>> >
>> > So I encourage you to check out:
>> >
>> > https://github.com/imduffy15/GSoC-2014
>> >
>> > This works out of the box.
>> >
>> > It is from Ian , it uses Vagrant boxes that are available in the
>> vagrant cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a
>> xenserver box for the hypervisor.
>> > You then build locally, 3306 is forwarded localhost, so it looks like
>> your db is local. NAT routing is setup nicely.
>> > Devcloud cfg file used .
>> >
>> > You start bhaissab ttylinux image.
>> >
>> > It uses Chef recipes ...
>> >
>> > It works out of the box.
>> >
>> > Enjoy the week-end,
>> >
>> > -Sebastien
>>
>>
>>
>> --
>> Daan
>>
>
>

Re: 2014-6-09 Japanese CloudStack Community Weekly Update

[ilya musayev]

You guys are doing great work, simply amazing, please keep it up!

On 6/8/14, 10:14 PM, Mayumi K wrote:

Hi everyone

Activities of Japanese CloudStack Community.

## Event

[6/12] JCSUG will hold a Meet-up in Hokkaido
[6/13] Interop Tokyo 2014 : JCSUG will have a session.
 http://www.interop.jp/2014/index2.html
[6/14] OSC Hokkaido: JCSUG will have a session and booth.
[6/22] July Tech Festa : JCSUG will have a session.
 http://2014.techfesta.jp/

[7/04] JCSUG will hold a Meet-up in Nagoya
[7/05] OSC Nagoya: JCSUG will have a session and booth.

[8/02] OSC Kansai@kyoto: JCSUG will have a session and booth.

If you have any comment, please let ad...@cloudstack.jp know.

Thanks,
JCSUG (Japan CloudStack User Group)
Mayumi Koshimizu (samem...@gmail.com)

--
Web: http://cloudstack.jp
Ustream http://www.ustream.tv/channel/cloudstackja
Twitter: @cloudstackja
Facebook: https://www.facebook.com/cloudstackjapan
Admin ML: ad...@cloudstack.jp
User ML: us...@cloudstack.jp

Re: hackathon CCCEU14

[Laszlo Hornyak]

Whatever I find company for, because sitting and working alone is what I
can do anytime :-)


On Fri, Jun 13, 2014 at 10:04 AM, Daan Hoogland 
wrote:

> kocka, go ahead and edit (though you can't work on all of those
> subjects during the hackathon, hope you realize that)
>
> On Thu, Jun 12, 2014 at 7:46 PM, Laszlo Hornyak
>  wrote:
> > Hi,
> >
> > Could you give me write permission to the wiki? Or you can just add me to
> > the wikipage, I will want to work a little bit on all of those :)
> >
> > Thank you,
> > Laszlo
> >
> >
> > On Tue, Jun 10, 2014 at 2:35 PM, Daan Hoogland 
> > wrote:
> >
> >> Hello everybody,
> >>
> >> Do we still want to have a Hackathon next CCC? we need to plan for the
> >> resources (noticably the room) pretty soon.
> >>
> >> On Thu, Jun 5, 2014 at 12:01 PM, Daan Hoogland
> >>  wrote:
> >> > People,
> >> >
> >> > I added two more hackathon subjects at
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Collaboration+Conference+EU
> >> > In doing so I saw no moderators on the hackathons that were already
> >> announced. We need moderators to have successful hackathons. If  you
> feel a
> >> hackathon subject is important enough to go through, please add your
> name
> >> in the wiki. Only hackathons with enough attendance will have resources
> >> assigned at the conference.
> >> >
> >> > \DaanH
> >> >
> >>
> >>
> >>
> >> --
> >> Daan
> >>
> >
> >
> >
> > --
> >
> > EOF
>
>
>
> --
> Daan
>



-- 

EOF

Re: Review Request 22554: CLOUDSTACK-6909 - fix marvin's handling of SMB credentials for storage

[John Dilley]

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

(Updated June 13, 2014, 4:53 p.m.)


Review request for cloudstack.


Changes
---

Updated diff with Santhosh's comments


Bugs: CLOUDSTACK-6909
https://issues.apache.org/jira/browse/CLOUDSTACK-6909


Repository: cloudstack-git


Description
---

Fix marvin's handling of details field for primary and secondary storage to 
cope with SMB credentials. This allows Hyper-V to work.


Diffs (updated)
-

  tools/marvin/marvin/deployDataCenter.py 22b78ab 

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


Testing
---

Tested deploydataCenter with this JSON:

{
   "dbSvr":{
  "dbSvr":"10.220.137.39",
  "passwd":"cloud",
  "db":"cloud",
  "port":3306,
  "user":"cloud"
   },
   "zones":[
  {
 "name":"XenRT-Zone-0",
 "guestcidraddress":"192.168.200.0/24",
 "dns1":"10.220.160.11",
 "physical_networks":[
{
   "XRT_VLANRangeSize":10,
   "name":"AdvPhyNetwork",
   "providers":[
  {
 "broadcastdomainrange":"ZONE",
 "name":"VirtualRouter"
  },
  {
 "broadcastdomainrange":"ZONE",
 "name":"VpcVirtualRouter"
  },
  {
 "broadcastdomainrange":"ZONE",
 "name":"InternalLbVm"
  }
   ],
   "broadcastdomainrange":"Zone",
   "vlan":"3000-3009",
   "traffictypes":[
  {
 "typ":"Guest"
  },
  {
 "typ":"Management"
  },
  {
 "typ":"Public"
  }
   ],
   "isolationmethods":[
  "VLAN"
   ]
}
 ],
 "ipranges":[
{
   "startip":"10.220.164.0",
   "endip":"10.220.164.9",
   "netmask":"255.255.240.0",
   "XRT_GuestIPRangeSize":10,
   "gateway":"10.220.160.1"
}
 ],
 "networktype":"Advanced",
 "pods":[
{
   "XRT_PodIPRangeSize":10,
   "name":"XenRT-Zone-0-Pod-0",
   "endip":"10.220.164.39",
   "startip":"10.220.164.30",
   "netmask":"255.255.240.0",
   "clusters":[
  {
 "XRT_HyperVHostIds":"0",
 "clustername":"XenRT-Zone-0-Pod-0-Cluster-0",
 "hypervisor":"hyperv",
 "primaryStorages":[
{
   "url":"cifs://10.220.163.45/storage/primary",
   "name":"XenRT-Zone-0-Pod-0-Primary-Store",
   "details":[
  {
 "user":"Administrator"
  },
  {
 "password":"xenroot01T"
  },
  {
 "domain":"XSQA"
  }
   ]
}
 ],
 "clustertype":"CloudManaged",
 "hosts":[
{
   "url":"http://10.220.163.45";,
   "username":"root",
   "password":"xenroot"
}
 ],
 "XRT_Hosts":1
  }
   ],
   "gateway":"10.220.160.1"
}
 ],
 "internaldns1":"10.220.160.11",
 "secondaryStorages":[
{
   "url":"cifs://10.220.163.45/storage/secondary",
   "details":{
  "domain":"XSQA",
  "password":"xenroot01T",
  "user":"Administrator"
   },
   "provider":"SMB"
}
 ]
  }
   ],
   "mgtSvr":[
  {
 "mgtSvrIp":"10.220.137.39",
 "passwd":"xenroot",
 "port":8096,
 "user":"root"
  }
   ]
}


Thanks,

John Dilley

Creating BareMetal templates from vmid via API

[nera nesic]

Hello,

Please forgive me for crossposting - I originally sent this to users, but
then realized dev was probably a more appropriate mailing list.

I am trying to create a BareMetal template based on vm id using the
CloudStack API. The API documentations suggests that this should be
possible by providing the virtual machine ID and a URL for template
storage. However, this doesn't work; I followed the API documentation,
provided the ostypeid, name, displaytext, virtualmachineid, and url, but I
got this error message:

“Failed to create private template record, neither volume ID nor snapshot
ID were specified. ”

So I took a look at the code, and while I did find the code which should
support BareMetal template creation from vmid in the BareMetalPxeManager,
it is not called from anywhere. The TemplateManager handles
CreateTemplateCommands which specify either a volume or a snapshot, but
doesn't deal with the BareMetal template creation in any way.

Is this omission made intentionally? Is the API capable of handling
creation of these templates in some other way, or should support for
BareMetal templates be added to the TemplateManager?


Regards,

-- 
*Nera Nešić*
Backend Developer

Mobile: (+354) 782 1337
n...@greenqloud.com 
www.greenqloud.com

Re: [PROPOSAL] Collect and provide generic key/value pairs to storage plug-ins

[Mike Tutkowski]

Thanks for the detailed response, John!

When Chris Suich (formerly from NetApp) and I talked about this several
months ago, we were thinking that this would replace the need for storage
tagging. However, as you point out, I now think it does not.

We were originally figuring that by specifically selecting a vendor (by
picking the applicable storage plug-in) that this removed the need for
storage tagging, but I see now that you might still want to further refine
within a given storage provider which primary storage CloudStack selects.

That being the case, if the user selects a specific storage plug-in, that
will be the first step in filtering and storage tagging will be the next.

Once I update the design, maybe you can take a look at it again. I can
include the new data types you listed.

Thanks!


On Fri, Jun 13, 2014 at 8:38 AM, John Burwell  wrote:

> Mike,
>
> I completely agree with the need to attach driver-specified key-value
> pairs to a storage driver (we have been batting this around for nearly a
> year).  However, I think this facility should be generalized to support all
> drivers (e.g. network, compute, etc) where storage maybe the first layer to
> implement it.  For example, we have a raft of places where vendor specific
> data/concepts leak into the object model and schema.  For example, in
> networking, we have vendor specific API calls. One of the main value
> propositions of a cloud platform is to provide a unified abstraction for
> underlying infrastructure components.  Furthermore, requiring vendor
> implements to add API calls further increases the complexity and effort
> required to support CloudStack — discouraging their participation.
>
> In terms of the design of itself, I don’t feel that the Map String> getPropertiesAndTypes is a rich enough semantic for such an
> extension facility.  First, it does not provide a mechanism to validate
> that the form and content of the values being set.  Second, it is
> incredible lose contract that does not exploit the Java compiler to ensure
> drivers are providing well-formed metadata to the CloudStack orchestration
> components.  Finally, it does not support notions such as hinting which
> fields are required (very useful for creating useful UIs) and constrained
> values (rendered as drop downs).  My thoughts are as follows:
>
>
>- Define an ExtenstionPropertyType enumeration with the following
>types permitted:
>   - STRING
>   - DATE
>   - NUMBER
>   - BOOLEAN
>   - The following methods as well:
>  - Class getType(): The underlying Java type used to represent
>  the type
>  - Object convertFromString(String aValue): Converts a value from
>  a string to the underlying Java type
>  - String convertToString(Object aValue): Converts a value to a
>  string from the underlying Java type
>   - Define a ExtensionPropertyDefinition interface that describes the
>following attributes about a extension property:
>   - String getName(): The name of the property conforming to JavaBean
>   standards (while we don’t support reflection, it’s a well known 
> standard by
>   Java developers …)
>   - ExtensionPropertyType getType():  The type of the property
>   - boolean isRequired(): Whether or not a value for the property is
>   required
>   - boolean isCollected(): Whether or not the property’s value is a
>   single value or collected (default to a list)
>   - Set getConstraints: A list of the values that constrain
>   the values of this extension property.
>   - List validate(Object aValue): A callback to validate a
>   value for this property definition — returning a list of strings 
> describing
>   the validation errors.  An empty list implies a valid value.  An 
> additional
>   nicety for this interface would be to define a type which the definition
>   would expect of the underlying value to be at runtime.
>- Introduce an Extendable interface that indicates that a type can
>have its data extended with a set of key-value pairs.  I would define the
>following methods:
>   - Set
>   getExtenstionPropertyDefinitions(): The set of extension property
>   descriptions
>   - Object getExtensionPropertyValue(String aPropertyName): Get a
>   value for an extension property
>   - List validateExtensionProperties(): Validates the values
>   of the extension properties
>
>
> There are likely pieces I missed and refinements to improve this design —
> I jotted it down off the top of my head.  However, we have to ensue that
> the semantic is rich enough to render friendly UIs, as well as, protect
> against GIGO (garbage in, garbage out).
>
> Finally, I would like to see the design expanded to explain when and where
> this information will pass into drivers for use.  As the design stands now,
> it does not explain how the data would actually be used during operation.
>  The scope of 

Re: DevCloud replacement

[Rohit Yadav]

On Fri, Jun 13, 2014 at 9:25 PM, Daan Hoogland 
wrote:

> Thanks Sebastien and of course Ian,
>
> I will try. BUT i think the reason is that xcp is not well supported
> and devcloud is not based on xenserver but on xcp or even a vanilla
> (debian/ubuntu?) xen. So will we continue on Ians path or go back and
> fix devcloud?
>

I think there is no point in supporting XCP, so we should continue with
Ian's path and start using/testing ACS with xenserver ( or xenproject).

Thanks Ian and Sebastien, trying it out now.

The ttylinux image is also accessible here:
http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd

Cheers.


>
> On Fri, Jun 13, 2014 at 5:36 PM, sebgoa  wrote:
> > Hi folks,
> >
> > As you know I love Devcloud, but it has its pains and lately it got
> broken in 4.3, and I don't think it works with 4.4.
> >
> > So I encourage you to check out:
> >
> > https://github.com/imduffy15/GSoC-2014
> >
> > This works out of the box.
> >
> > It is from Ian , it uses Vagrant boxes that are available in the vagrant
> cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a xenserver
> box for the hypervisor.
> > You then build locally, 3306 is forwarded localhost, so it looks like
> your db is local. NAT routing is setup nicely.
> > Devcloud cfg file used .
> >
> > You start bhaissab ttylinux image.
> >
> > It uses Chef recipes ...
> >
> > It works out of the box.
> >
> > Enjoy the week-end,
> >
> > -Sebastien
>
>
>
> --
> Daan
>

Re: DevCloud replacement

[Daan Hoogland]

Thanks Sebastien and of course Ian,

I will try. BUT i think the reason is that xcp is not well supported
and devcloud is not based on xenserver but on xcp or even a vanilla
(debian/ubuntu?) xen. So will we continue on Ians path or go back and
fix devcloud?

On Fri, Jun 13, 2014 at 5:36 PM, sebgoa  wrote:
> Hi folks,
>
> As you know I love Devcloud, but it has its pains and lately it got broken in 
> 4.3, and I don't think it works with 4.4.
>
> So I encourage you to check out:
>
> https://github.com/imduffy15/GSoC-2014
>
> This works out of the box.
>
> It is from Ian , it uses Vagrant boxes that are available in the vagrant 
> cloud . It sets up NFS and MySql on a centOS6.5 VM, and uses a xenserver box 
> for the hypervisor.
> You then build locally, 3306 is forwarded localhost, so it looks like your db 
> is local. NAT routing is setup nicely.
> Devcloud cfg file used .
>
> You start bhaissab ttylinux image.
>
> It uses Chef recipes …
>
> It works out of the box.
>
> Enjoy the week-end,
>
> -Sebastien



-- 
Daan

Re: [PROPOSAL] Collect and provide generic key/value pairs to storage plug-ins

[Daan Hoogland]

+1 to Johns first comment; I think we need it in a more generic way
then for storage plugins. I am sure network
providers/loadbalancers/firewalls need such properties as well.

John, should we make your ExtensionPropertyType a generic and let the
convert-methods deal with the parameter types instead of with Objects?

greatings

On Fri, Jun 13, 2014 at 4:38 PM, John Burwell  wrote:
> Mike,
>
> I completely agree with the need to attach driver-specified key-value pairs 
> to a storage driver (we have been batting this around for nearly a year).  
> However, I think this facility should be generalized to support all drivers 
> (e.g. network, compute, etc) where storage maybe the first layer to implement 
> it.  For example, we have a raft of places where vendor specific 
> data/concepts leak into the object model and schema.  For example, in 
> networking, we have vendor specific API calls. One of the main value 
> propositions of a cloud platform is to provide a unified abstraction for 
> underlying infrastructure components.  Furthermore, requiring vendor 
> implements to add API calls further increases the complexity and effort 
> required to support CloudStack — discouraging their participation.
>
> In terms of the design of itself, I don’t feel that the Map 
> getPropertiesAndTypes is a rich enough semantic for such an extension 
> facility.  First, it does not provide a mechanism to validate that the form 
> and content of the values being set.  Second, it is incredible lose contract 
> that does not exploit the Java compiler to ensure drivers are providing 
> well-formed metadata to the CloudStack orchestration components.  Finally, it 
> does not support notions such as hinting which fields are required (very 
> useful for creating useful UIs) and constrained values (rendered as drop 
> downs).  My thoughts are as follows:
>
> Define an ExtenstionPropertyType enumeration with the following types 
> permitted:
> STRING
> DATE
> NUMBER
> BOOLEAN
> The following methods as well:
> Class getType(): The underlying Java type used to represent the type
> Object convertFromString(String aValue): Converts a value from a string to 
> the underlying Java type
> String convertToString(Object aValue): Converts a value to a string from the 
> underlying Java type
> Define a ExtensionPropertyDefinition interface that describes the following 
> attributes about a extension property:
> String getName(): The name of the property conforming to JavaBean standards 
> (while we don’t support reflection, it’s a well known standard by Java 
> developers …)
> ExtensionPropertyType getType():  The type of the property
> boolean isRequired(): Whether or not a value for the property is required
> boolean isCollected(): Whether or not the property’s value is a single value 
> or collected (default to a list)
> Set getConstraints: A list of the values that constrain the values of 
> this extension property.
> List validate(Object aValue): A callback to validate a value for this 
> property definition — returning a list of strings describing the validation 
> errors.  An empty list implies a valid value.  An additional nicety for this 
> interface would be to define a type which the definition would expect of the 
> underlying value to be at runtime.
> Introduce an Extendable interface that indicates that a type can have its 
> data extended with a set of key-value pairs.  I would define the following 
> methods:
> Set getExtenstionPropertyDefinitions(): The set 
> of extension property descriptions
> Object getExtensionPropertyValue(String aPropertyName): Get a value for an 
> extension property
> List validateExtensionProperties(): Validates the values of the 
> extension properties
>
> There are likely pieces I missed and refinements to improve this design — I 
> jotted it down off the top of my head.  However, we have to ensue that the 
> semantic is rich enough to render friendly UIs, as well as, protect against 
> GIGO (garbage in, garbage out).
>
> Finally, I would like to see the design expanded to explain when and where 
> this information will pass into drivers for use.  As the design stands now, 
> it does not explain how the data would actually be used during operation.  
> The scope of these changes is important to understand for both impact 
> analysis and driver developers and implementors.  Also, I don’t understand 
> how the addition of generic key-values to drivers would eliminate tags.  As I 
> understand them, tags are used to establish valid combinations of drivers 
> (e.g. mutual exclusion) to avoid defining an unimplementable infrastructure 
> configuration.  While I agree with the desire to eliminate them, I don’t 
> understand how such a facility would contribute to that goal.
>
> Great work putting together an initial design, and getting this important 
> conversation started.
>
> Thanks,
> -John
>
> On Jun 10, 2014, at 6:26 PM, Mike Tutkowski  
> wrote:
>
>> Hi,
>>
>> Please feel free to review the follow

DevCloud replacement

[sebgoa]

Hi folks,

As you know I love Devcloud, but it has its pains and lately it got broken in 
4.3, and I don't think it works with 4.4.

So I encourage you to check out:

https://github.com/imduffy15/GSoC-2014

This works out of the box.

It is from Ian , it uses Vagrant boxes that are available in the vagrant cloud 
. It sets up NFS and MySql on a centOS6.5 VM, and uses a xenserver box for the 
hypervisor.
You then build locally, 3306 is forwarded localhost, so it looks like your db 
is local. NAT routing is setup nicely.
Devcloud cfg file used .

You start bhaissab ttylinux image.

It uses Chef recipes …

It works out of the box.

Enjoy the week-end,

-Sebastien

Re: [ACS44] CLOUDSTACK-6464

[Daan Hoogland]

ok, please note discussions on 4.3.1 and my comment in it. The db
upgrade solution will go in the alleged 4.3.1! I changed the bug to
fix-version 4.4.0 but will put it back to 4.3.1. It is solved this way
in the coming 4.4.0 as well.

On Fri, Jun 13, 2014 at 2:54 PM, Simon Weller  wrote:
> Daan,
>
> Thanks for following up.
>
> Both Marcus and Edison have been involved looking at this bug, and it appears 
> to be related to what CS expects in the cloud.vlan table between releases. 
> This issue affects both untagged networks and tagged networks in the same 
> manner, and simply changing the vlan_id column data format seems to fix the 
> problem. A couple of us (myself included) have tested a database fix and 
> commented success in the issue notes. Since our testing, I haven't seen any 
> comment on how this should be fixed permanently (either a database data 
> change during upgrade, or code to support the older data format for original 
> installs prior to 4.3). My preference would be a data change, as that's 
> easier to maintain moving forward.
>
> I still think a note should be posted on 4.3, suggesting people to avoid it 
> for KVM upgrades, or at the very least pointing them to this issue so they 
> can updated the data format manually post upgrade, and prior to restarting 
> their VRs.
> -
>  Si
>
> 
> From: Daan Hoogland 
> Sent: Thursday, June 12, 2014 8:47 AM
> To: dev
> Subject: Re: [ACS44] CLOUDSTACK-6464
>
> Simon,
>
> I found you in my spam box looking for my colleague, Hugo. Didn't find
> him there;)
>
> I guess you're request is no longer actual, The bug is, no doubt. Can
> you give an update on it?
>
> On Wed, May 14, 2014 at 1:00 AM, Simon Weller  wrote:
>> All,
>>
>>
>> Could someone with knowledge of the KVM traffic label code take a look at 
>> https://issues.apache.org/jira/browse/CLOUDSTACK-6464?
>>
>>
>> It appears egress traffic is broken currently when basic or advanced 
>> networking is in use with traffic labels on KVM.
>>
>>
>> Daan,
>>
>>
>> Could you change the tag for this to 4.4 from 4.3.1, and in my opinion this 
>> should be a blocker, as it completely breaks KVM VR networking.
>>
>>
>> Thanks,
>>
>>
>> - Si
>>
>
>
>
> --
> Daan



-- 
Daan

RE: Unable to create a Template from ROOT Volume Snapshot

[Venkata Suneel Babu Mallela]

I'm using Apache CloudStack 4.2.0 and XenServer 6.0.2.

Thank you,
Suneel Mallela

From: Venkata Suneel Babu Mallela
Sent: Friday, June 13, 2014 11:31 AM
To: us...@cloudstack.apache.org; dev@cloudstack.apache.org
Subject: Unable to create a Template from ROOT Volume Snapshot

Hi All,

I tried to create a template from a ROOT volume snapshot and I got the 
following error

"Failed to create templatejava.io.FileNotFoundException: 
/mnt/SecStorage/*/template/tmpl/*/*/template.properties (No such file or 
directory)"

Please help me to resolve this problem.

Thank you,
Suneel Mallela

Re: Code Documentation

[Rohit Yadav]

On Wed, Jun 11, 2014 at 9:58 PM, Santhosh Edukulla <
santhosh.eduku...@citrix.com> wrote:

> Hi All,
>
> Many of code areas under CS, currently don't have enough documentation i
> believe, we have few one liner comments at places. But, largely, was
> missing at various code areas.
>
> We in one of our earlier project, used to enforce strictly a template for
> comments\documentation for every new function added. These comments were
> later retrieved automatically to build code documentation easily. This gets
> enforced during review itself, or otherwise review wont be accepted.  It
> will make the flow lot easier to understand some times i believe.
>
> Please add atleast basic description for every  major
> interface\class\function, description for input\output arguments for
> individual entities.
>

IMO we should prefer writing code so it documents itself and we save
ourselves from maintaining both code and comments.

Regards.


>
> EX: Currently, for below we dont have any comments in general.
>
> public boolean shutdownNetwork(final long networkId, ReservationContext
> context, boolean cleanupElements)
>
>
> Regards,
> Santhosh
>
>

Re: [PROPOSAL] Collect and provide generic key/value pairs to storage plug-ins

[John Burwell]

Mike,

I completely agree with the need to attach driver-specified key-value pairs to 
a storage driver (we have been batting this around for nearly a year).  
However, I think this facility should be generalized to support all drivers 
(e.g. network, compute, etc) where storage maybe the first layer to implement 
it.  For example, we have a raft of places where vendor specific data/concepts 
leak into the object model and schema.  For example, in networking, we have 
vendor specific API calls. One of the main value propositions of a cloud 
platform is to provide a unified abstraction for underlying infrastructure 
components.  Furthermore, requiring vendor implements to add API calls further 
increases the complexity and effort required to support CloudStack — 
discouraging their participation.

In terms of the design of itself, I don’t feel that the Map 
getPropertiesAndTypes is a rich enough semantic for such an extension facility. 
 First, it does not provide a mechanism to validate that the form and content 
of the values being set.  Second, it is incredible lose contract that does not 
exploit the Java compiler to ensure drivers are providing well-formed metadata 
to the CloudStack orchestration components.  Finally, it does not support 
notions such as hinting which fields are required (very useful for creating 
useful UIs) and constrained values (rendered as drop downs).  My thoughts are 
as follows:

Define an ExtenstionPropertyType enumeration with the following types permitted:
STRING
DATE
NUMBER
BOOLEAN
The following methods as well:
Class getType(): The underlying Java type used to represent the type
Object convertFromString(String aValue): Converts a value from a string to the 
underlying Java type
String convertToString(Object aValue): Converts a value to a string from the 
underlying Java type
Define a ExtensionPropertyDefinition interface that describes the following 
attributes about a extension property:
String getName(): The name of the property conforming to JavaBean standards 
(while we don’t support reflection, it’s a well known standard by Java 
developers …)
ExtensionPropertyType getType():  The type of the property
boolean isRequired(): Whether or not a value for the property is required
boolean isCollected(): Whether or not the property’s value is a single value or 
collected (default to a list)
Set getConstraints: A list of the values that constrain the values of 
this extension property.
List validate(Object aValue): A callback to validate a value for this 
property definition — returning a list of strings describing the validation 
errors.  An empty list implies a valid value.  An additional nicety for this 
interface would be to define a type which the definition would expect of the 
underlying value to be at runtime. 
Introduce an Extendable interface that indicates that a type can have its data 
extended with a set of key-value pairs.  I would define the following methods:
Set getExtenstionPropertyDefinitions(): The set 
of extension property descriptions
Object getExtensionPropertyValue(String aPropertyName): Get a value for an 
extension property
List validateExtensionProperties(): Validates the values of the 
extension properties

There are likely pieces I missed and refinements to improve this design — I 
jotted it down off the top of my head.  However, we have to ensue that the 
semantic is rich enough to render friendly UIs, as well as, protect against 
GIGO (garbage in, garbage out).  

Finally, I would like to see the design expanded to explain when and where this 
information will pass into drivers for use.  As the design stands now, it does 
not explain how the data would actually be used during operation.  The scope of 
these changes is important to understand for both impact analysis and driver 
developers and implementors.  Also, I don’t understand how the addition of 
generic key-values to drivers would eliminate tags.  As I understand them, tags 
are used to establish valid combinations of drivers (e.g. mutual exclusion) to 
avoid defining an unimplementable infrastructure configuration.  While I agree 
with the desire to eliminate them, I don’t understand how such a facility would 
contribute to that goal.

Great work putting together an initial design, and getting this important 
conversation started.

Thanks,
-John

On Jun 10, 2014, at 6:26 PM, Mike Tutkowski  
wrote:

> Hi,
> 
> Please feel free to review the following proposal for 4.5:
> 
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42566111
> 
> Here is the summary:
> Today the way you associate a Compute Offering (CO) or a Disk Offering (DO) 
> with a Primary Storage (PS) is via storage tagging.
> This has some benefits and drawbacks.
> One benefit is being able to have some level of vendor independence from the 
> point of view of the CO or DO. For example, if the storage tag of a DO is 
> "Fast", then this can be satisfied by PS that describes itself as "Fast", 
> regardless of 

Re: Review Request 22549: CLOUDSTACK-6887: Fixing account cleanup issue across multiple test cases

[ASF Subversion and Git Services]

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


Commit 59a98839ce895cef6e4864f37fd831805d1da8f1 in cloudstack's branch 
refs/heads/master from Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=59a9883 ]

CLOUDSTACK-6887: Fixing account cleanup issue across multiple test cases


- ASF Subversion and Git Services


On June 13, 2014, 7:42 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22549/
> ---
> 
> (Updated June 13, 2014, 7:42 a.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-6887
> https://issues.apache.org/jira/browse/CLOUDSTACK-6887
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixing account cleanup issues across multiple test cases. This patch contains 
> test cases fixes in 8 test suites. Will put up new patch for remaining test 
> suites as and when I fix them.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_add_remove_network.py 20aefe4 
>   test/integration/component/test_persistent_networks.py ab1e2c2 
>   test/integration/component/test_projects.py c593fb6 
>   test/integration/component/test_snapshot_gc.py 42c361c 
>   test/integration/component/test_snapshot_limits.py 95c6432 
>   test/integration/component/test_usage.py 03823be 
>   test/integration/component/test_volumes.py b5b08e2 
>   test/integration/smoke/test_affinity_groups.py 4f3f9ec 
> 
> Diff: https://reviews.apache.org/r/22549/diff/
> 
> 
> Testing
> ---
> 
> Tested on VMware.
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 22549: CLOUDSTACK-6887: Fixing account cleanup issue across multiple test cases

[ASF Subversion and Git Services]

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


Commit b849b7ee3d9b4a141c2eb3fd689d197ed20c4581 in cloudstack's branch 
refs/heads/4.4-forward from Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b849b7e ]

CLOUDSTACK-6887: Fixing account cleanup issue across multiple test cases


- ASF Subversion and Git Services


On June 13, 2014, 7:42 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22549/
> ---
> 
> (Updated June 13, 2014, 7:42 a.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-6887
> https://issues.apache.org/jira/browse/CLOUDSTACK-6887
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixing account cleanup issues across multiple test cases. This patch contains 
> test cases fixes in 8 test suites. Will put up new patch for remaining test 
> suites as and when I fix them.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_add_remove_network.py 20aefe4 
>   test/integration/component/test_persistent_networks.py ab1e2c2 
>   test/integration/component/test_projects.py c593fb6 
>   test/integration/component/test_snapshot_gc.py 42c361c 
>   test/integration/component/test_snapshot_limits.py 95c6432 
>   test/integration/component/test_usage.py 03823be 
>   test/integration/component/test_volumes.py b5b08e2 
>   test/integration/smoke/test_affinity_groups.py 4f3f9ec 
> 
> Diff: https://reviews.apache.org/r/22549/diff/
> 
> 
> Testing
> ---
> 
> Tested on VMware.
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

RE: [ACS44] CLOUDSTACK-6464

[Simon Weller]

Daan,

Thanks for following up.

Both Marcus and Edison have been involved looking at this bug, and it appears 
to be related to what CS expects in the cloud.vlan table between releases. This 
issue affects both untagged networks and tagged networks in the same manner, 
and simply changing the vlan_id column data format seems to fix the problem. A 
couple of us (myself included) have tested a database fix and commented success 
in the issue notes. Since our testing, I haven't seen any comment on how this 
should be fixed permanently (either a database data change during upgrade, or 
code to support the older data format for original installs prior to 4.3). My 
preference would be a data change, as that's easier to maintain moving forward.

I still think a note should be posted on 4.3, suggesting people to avoid it for 
KVM upgrades, or at the very least pointing them to this issue so they can 
updated the data format manually post upgrade, and prior to restarting their 
VRs.
-
 Si


From: Daan Hoogland 
Sent: Thursday, June 12, 2014 8:47 AM
To: dev
Subject: Re: [ACS44] CLOUDSTACK-6464

Simon,

I found you in my spam box looking for my colleague, Hugo. Didn't find
him there;)

I guess you're request is no longer actual, The bug is, no doubt. Can
you give an update on it?

On Wed, May 14, 2014 at 1:00 AM, Simon Weller  wrote:
> All,
>
>
> Could someone with knowledge of the KVM traffic label code take a look at 
> https://issues.apache.org/jira/browse/CLOUDSTACK-6464?
>
>
> It appears egress traffic is broken currently when basic or advanced 
> networking is in use with traffic labels on KVM.
>
>
> Daan,
>
>
> Could you change the tag for this to 4.4 from 4.3.1, and in my opinion this 
> should be a blocker, as it completely breaks KVM VR networking.
>
>
> Thanks,
>
>
> - Si
>



--
Daan

Re: [ACS44] cherry-pick request

[Daan Hoogland]

both pulled

On Fri, Jun 13, 2014 at 1:53 PM, Murali Reddy  wrote:
> Daan,
>
> Please cherry-pick below commits in 4.4-forward into 4.4
>
> commit be937a08213f06a801cf07d19867d48dad35d19f
> CLOUDSTACK-6832: [OVS]vnet is not released even the network is deleted
>
> fix ensures allocated VNET is released during network shutdown
>
> commit 9dfbdb5ffd2f0981651bc98f1c5d71718a24a29f
> CLOUDSTACK-6749: [OVS] xe network-param-get with
> param-key=is-ovs-vpc-distributed-vr-network alway returns error
>
> fixing unnecessary errors in the logs
>
>
> Thanks.
>



-- 
Daan

[ACS44] cherry-pick request

[Murali Reddy]

Daan, 

Please cherry-pick below commits in 4.4-forward into 4.4

commit be937a08213f06a801cf07d19867d48dad35d19f
CLOUDSTACK-6832: [OVS]vnet is not released even the network is deleted

fix ensures allocated VNET is released during network shutdown

commit 9dfbdb5ffd2f0981651bc98f1c5d71718a24a29f
CLOUDSTACK-6749: [OVS] xe network-param-get with
param-key=is-ovs-vpc-distributed-vr-network alway returns error

fixing unnecessary errors in the logs


Thanks.

Re: Review Request 22549: CLOUDSTACK-6887: Fixing account cleanup issue across multiple test cases

[Girish Shilamkar]

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

Ship it!


Ship It!

- Girish Shilamkar


On June 13, 2014, 7:42 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22549/
> ---
> 
> (Updated June 13, 2014, 7:42 a.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-6887
> https://issues.apache.org/jira/browse/CLOUDSTACK-6887
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixing account cleanup issues across multiple test cases. This patch contains 
> test cases fixes in 8 test suites. Will put up new patch for remaining test 
> suites as and when I fix them.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_add_remove_network.py 20aefe4 
>   test/integration/component/test_persistent_networks.py ab1e2c2 
>   test/integration/component/test_projects.py c593fb6 
>   test/integration/component/test_snapshot_gc.py 42c361c 
>   test/integration/component/test_snapshot_limits.py 95c6432 
>   test/integration/component/test_usage.py 03823be 
>   test/integration/component/test_volumes.py b5b08e2 
>   test/integration/smoke/test_affinity_groups.py 4f3f9ec 
> 
> Diff: https://reviews.apache.org/r/22549/diff/
> 
> 
> Testing
> ---
> 
> Tested on VMware.
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: [DISCUSS] [PROPOSAL] Implementation of DNS Provider for Bind (for 4.5)

[Rohit Yadav]

Hi Silvano,

On Fri, Jun 13, 2014 at 10:51 AM, Silvano Nogueira Buback <
silv...@corp.globo.com> wrote:

> Hi there,
>
>
> I work at Globo.com, a media company in Brazil. Here we use a cloudstack
> private network with an advanced zone setup (isolated vlans).
>
> For some couple of reasons, the name of virtual machine needs to be
> available not only on virtual router network context, but on our internal
> DNS servers.
>
> Our proposal is integrate cloudstack (v 4.5) with DNS server (Bind server)
> thru an open source API written by globo.com called DNSAPI. More info at
> https://github.com/globocom/Dns-Api.
>

Thanks for the proposal.

I recommend that you document your design goals in 4.5 or above design docs
wiki:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.5+Design+Documents

I saw the video you shared, it looked seamless but I could not figure out
how the ACS plugin interacts with the DNS provider. The API library you
mentioned is written in Ruby, so how does it integrate or work with the dns
plugin in ACS, is it over HTTP or RPC/Thrift?

Regards.


>
> To make this implementation of DNS provider, we based our plugin on
> "dns-notifier", but we had to add more classes for our implementation.
>
> * DnsAPINetworkDAO to manage the networkDomain for each network.
> * DnsAPIVirtualMachineDAO to manage DNS records for vms.
> * DnsAPIElement, this class implements the provider itself.
> * DnsAPIResource, implements all communications with DNSAPI
> (ServerResource).
>
> Besides this classes, another one was necessary to the call to
> DnsAPIResource and return the answer, and one API command was created to
> configure the provider in Zone.
>
> Above a video that show you how everything was integrated.
>
> https://www.youtube.com/watch?v=fAB53T_NZMI
>
> We really appreciate all your comments about our implementation,
>
> thanks in advance
> PS: Sorry about duplicated e-mail in mailing list, but I forget to use
> DISCUSS and send using company e-mail)
>

Re: [ACS44] Cherry pick for CLOUDSTACK-6897, CLOUDSTACK-6868, CLOUDSTACK-6872, CLOUDSTACK-6867, CLOUDSTACK-6865

[Daan Hoogland]

4 picked

On Fri, Jun 13, 2014 at 12:25 PM, Anshul Gangwar
 wrote:
> Hi Daan/Hugo,
>
>
>
> Can you please cherry-pick following commits from 4.4-forward to 4.4:
>
>
>
> commit 2dc9e2c530b36efc4c4684e13ae0412103925d05
>
> Author: Anshul Gangwar 
>
> Date:   Thu Jun 12 13:54:56 2014 +0530
>
>
>
> CLOUDSTACK-6897: when we try to attach the uploaded/allocated volume to
> a VM on zwps, then we were passing the podId of VM instead of storage pool
> to storage allocator. This resulting in use of Clusterscope s
>
>
>
> commit cef29948a708fbbae1261dbd8b6a13e4da19c703
>
> Author: Anshul Gangwar 
>
> Date:   Wed Jun 11 11:04:35 2014 +0530
>
>
>
> CLOUDSTACK-6872: [hyperv] removed the redundant connectToRemote,
> DisconnectRemote methods which in turn fixes this bug. connectToRemote was
> used to connect to share, but once the share is domain joined we don
>
>
>
> commit 2e49ef73bfcb548cf19d1230f00a0510b7d09150
>
> Author: Anshul Gangwar 
>
> Date:   Tue Jun 10 16:43:40 2014 +0530
>
>
>
> CLOUDSTACK-6867: Added option to upload the volume in VHDX format
>
>
>
> commit ebff469b46551f8613013e80aa0386203a9c7912
>
> Author: Anshul Gangwar 
>
> Date:   Tue Jun 10 16:28:32 2014 +0530
>
>
>
> CLOUDSTACK-6865 , CLOUDSTACK-6868: [hyperv] while attaching the volume
> we were changing the volume's Image format to hypervisor's default Image
> format, hence it was failing to find the volume with vhdx format
>
>
>
> Thanks,
>
> Anshul
>
>



-- 
Daan

Re: Review Request 22414: CLOUDSTACK-6865, CLOUDSTACK-6868: [hyper-v] attach volume of vhd format volume is failing

[ASF Subversion and Git Services]

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


Commit a951b51523069e72e5cd1e503df11b9370b6d6d8 in cloudstack's branch 
refs/heads/4.4 from Anshul Gangwar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a951b51 ]

CLOUDSTACK-6865 , CLOUDSTACK-6868: [hyperv] while attaching the volume we were 
changing the volume's Image format to hypervisor's default Image format, hence 
it was failing to find the volume with vhdx format. Now changed the behavior to 
set Image Format for volume only when it is not set

(cherry picked from commit ebff469b46551f8613013e80aa0386203a9c7912)


- ASF Subversion and Git Services


On June 10, 2014, 11:23 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22414/
> ---
> 
> (Updated June 10, 2014, 11:23 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6865 and CLOUDSTACK-6868
> https://issues.apache.org/jira/browse/CLOUDSTACK-6865
> https://issues.apache.org/jira/browse/CLOUDSTACK-6868
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> while attaching the volume we were changing the volume's Image format to 
> hypervisor's default Image format, hence it was failing to find the volume 
> with vhdx format
> Now changed the behavior to set Image Format for volume only when it is 
> not set
> 
> 
> Diffs
> -
> 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  064ffca 
> 
> Diff: https://reviews.apache.org/r/22414/diff/
> 
> 
> Testing
> ---
> 
> verified by uploading the vhd volume and attaching it to VM
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

Re: Review Request 22415: CLOUDSTACK-6867: added the option for vhdx image format in upload volume

[ASF Subversion and Git Services]

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


Commit 2c5f352e94e071113ae1bbf74435662568902043 in cloudstack's branch 
refs/heads/4.4 from Anshul Gangwar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2c5f352 ]

CLOUDSTACK-6867: Added option to upload the volume in VHDX format

(cherry picked from commit 2e49ef73bfcb548cf19d1230f00a0510b7d09150)


- ASF Subversion and Git Services


On June 11, 2014, 5:20 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22415/
> ---
> 
> (Updated June 11, 2014, 5:20 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6867
> https://issues.apache.org/jira/browse/CLOUDSTACK-6867
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> added the option for vhdx image format in upload volume
> 
> 
> Diffs
> -
> 
>   ui/scripts/storage.js 604f09d 
> 
> Diff: https://reviews.apache.org/r/22415/diff/
> 
> 
> Testing
> ---
> 
> verified by opening the upload volume dialog in UI
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

Re: Review Request 22452: CLOUDSTACK-6872 : removed the redundant connectToRemote method

[ASF Subversion and Git Services]

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


Commit ef0cec938165fdf3531f92dc8f4c2930ff95fa5e in cloudstack's branch 
refs/heads/4.4 from Anshul Gangwar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ef0cec9 ]

CLOUDSTACK-6872: [hyperv] removed the redundant connectToRemote, 
DisconnectRemote methods which in turn fixes this bug. connectToRemote was used 
to connect to share, but once the share is domain joined we don't need this 
method as we already have required permissions

(cherry picked from commit cef29948a708fbbae1261dbd8b6a13e4da19c703)


- ASF Subversion and Git Services


On June 11, 2014, 7:31 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22452/
> ---
> 
> (Updated June 11, 2014, 7:31 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6872
> https://issues.apache.org/jira/browse/CLOUDSTACK-6872
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Removed the redundant connectTORemote method in Hyper-v Agent. We dont't need 
> this method as share is domain joined so it has all the required permissions. 
> Removal of this method fixes this bug also.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/HypervResourceController.cs
>  0ad95b8 
>   plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/Utils.cs 
> c8e951e 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/WmiCallsV2.cs 
> 372f848 
> 
> Diff: https://reviews.apache.org/r/22452/diff/
> 
> 
> Testing
> ---
> 
> tested that volume operations are working fine after removal of this method
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

Re: Review Request 22414: CLOUDSTACK-6865, CLOUDSTACK-6868: [hyper-v] attach volume of vhd format volume is failing

[ASF Subversion and Git Services]

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


Commit a951b51523069e72e5cd1e503df11b9370b6d6d8 in cloudstack's branch 
refs/heads/4.4 from Anshul Gangwar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a951b51 ]

CLOUDSTACK-6865 , CLOUDSTACK-6868: [hyperv] while attaching the volume we were 
changing the volume's Image format to hypervisor's default Image format, hence 
it was failing to find the volume with vhdx format. Now changed the behavior to 
set Image Format for volume only when it is not set

(cherry picked from commit ebff469b46551f8613013e80aa0386203a9c7912)


- ASF Subversion and Git Services


On June 10, 2014, 11:23 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22414/
> ---
> 
> (Updated June 10, 2014, 11:23 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6865 and CLOUDSTACK-6868
> https://issues.apache.org/jira/browse/CLOUDSTACK-6865
> https://issues.apache.org/jira/browse/CLOUDSTACK-6868
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> while attaching the volume we were changing the volume's Image format to 
> hypervisor's default Image format, hence it was failing to find the volume 
> with vhdx format
> Now changed the behavior to set Image Format for volume only when it is 
> not set
> 
> 
> Diffs
> -
> 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  064ffca 
> 
> Diff: https://reviews.apache.org/r/22414/diff/
> 
> 
> Testing
> ---
> 
> verified by uploading the vhd volume and attaching it to VM
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

Re: Review Request 22500: CLOUDSTACK-6897: In a Multi cluster setup attach of a uploaded volume to a VM on zwps is failing with scope conflict

[ASF Subversion and Git Services]

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


Commit 117c8fe5b0e1b9f1045cbf65e3285fbf205770bf in cloudstack's branch 
refs/heads/4.4 from Anshul Gangwar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=117c8fe ]

CLOUDSTACK-6897: when we try to attach the uploaded/allocated volume to a VM on 
zwps, then we were passing the podId of VM instead of storage pool to storage 
allocator. This resulting in use of Clusterscope storage allocator, allocating 
a storage pool for VM on zwps beacuse of pod id not null. This was resulting in 
scope conflict later

(cherry picked from commit 2dc9e2c530b36efc4c4684e13ae0412103925d05)


- ASF Subversion and Git Services


On June 13, 2014, 9:08 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22500/
> ---
> 
> (Updated June 13, 2014, 9:08 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6897
> https://issues.apache.org/jira/browse/CLOUDSTACK-6897
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> when we try to attach the uploaded/allocated volume to a VM on zwps,
>  then we were passing the podId of VM instead of storage pool to storage 
> allocator.
>  This resulting in use of Clusterscope storage allocator, allocating a 
> storage pool for VM on zwps beacuse of pod id not null.
>   This was resulting in scope conflict later
> 
> 
> Diffs
> -
> 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  3cf8c6c 
> 
> Diff: https://reviews.apache.org/r/22500/diff/
> 
> 
> Testing
> ---
> 
> tested by uploading a volume and attaching it to vm on zwps in multi cluster 
> setup
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

[ACS44] Cherry pick for CLOUDSTACK-6897, CLOUDSTACK-6868, CLOUDSTACK-6872, CLOUDSTACK-6867, CLOUDSTACK-6865

[Anshul Gangwar]

Hi Daan/Hugo,



Can you please cherry-pick following commits from 4.4-forward to 4.4:

commit 2dc9e2c530b36efc4c4684e13ae0412103925d05
Author: Anshul Gangwar 
Date:   Thu Jun 12 13:54:56 2014 +0530

CLOUDSTACK-6897: when we try to attach the uploaded/allocated volume to a 
VM on zwps, then we were passing the podId of VM instead of storage pool to 
storage allocator. This resulting in use of Clusterscope s

commit cef29948a708fbbae1261dbd8b6a13e4da19c703
Author: Anshul Gangwar 
Date:   Wed Jun 11 11:04:35 2014 +0530

CLOUDSTACK-6872: [hyperv] removed the redundant connectToRemote, 
DisconnectRemote methods which in turn fixes this bug. connectToRemote was used 
to connect to share, but once the share is domain joined we don

commit 2e49ef73bfcb548cf19d1230f00a0510b7d09150
Author: Anshul Gangwar 
Date:   Tue Jun 10 16:43:40 2014 +0530

CLOUDSTACK-6867: Added option to upload the volume in VHDX format

commit ebff469b46551f8613013e80aa0386203a9c7912
Author: Anshul Gangwar 
Date:   Tue Jun 10 16:28:32 2014 +0530

CLOUDSTACK-6865 , CLOUDSTACK-6868: [hyperv] while attaching the volume we 
were changing the volume's Image format to hypervisor's default Image format, 
hence it was failing to find the volume with vhdx format

Thanks,
Anshul

Re: Review Request 22554: CLOUDSTACK-6909 - fix marvin's handling of SMB credentials for storage

[Santhosh Edukulla]

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



tools/marvin/marvin/deployDataCenter.py


Just use "in" instead


- Santhosh Edukulla


On June 13, 2014, 9:17 a.m., John Dilley wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22554/
> ---
> 
> (Updated June 13, 2014, 9:17 a.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Bugs: CLOUDSTACK-6909
> https://issues.apache.org/jira/browse/CLOUDSTACK-6909
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fix marvin's handling of details field for primary and secondary storage to 
> cope with SMB credentials. This allows Hyper-V to work.
> 
> 
> Diffs
> -
> 
>   tools/marvin/marvin/deployDataCenter.py 22b78ab 
> 
> Diff: https://reviews.apache.org/r/22554/diff/
> 
> 
> Testing
> ---
> 
> Tested deploydataCenter with this JSON:
> 
> {
>"dbSvr":{
>   "dbSvr":"10.220.137.39",
>   "passwd":"cloud",
>   "db":"cloud",
>   "port":3306,
>   "user":"cloud"
>},
>"zones":[
>   {
>  "name":"XenRT-Zone-0",
>  "guestcidraddress":"192.168.200.0/24",
>  "dns1":"10.220.160.11",
>  "physical_networks":[
> {
>"XRT_VLANRangeSize":10,
>"name":"AdvPhyNetwork",
>"providers":[
>   {
>  "broadcastdomainrange":"ZONE",
>  "name":"VirtualRouter"
>   },
>   {
>  "broadcastdomainrange":"ZONE",
>  "name":"VpcVirtualRouter"
>   },
>   {
>  "broadcastdomainrange":"ZONE",
>  "name":"InternalLbVm"
>   }
>],
>"broadcastdomainrange":"Zone",
>"vlan":"3000-3009",
>"traffictypes":[
>   {
>  "typ":"Guest"
>   },
>   {
>  "typ":"Management"
>   },
>   {
>  "typ":"Public"
>   }
>],
>"isolationmethods":[
>   "VLAN"
>]
> }
>  ],
>  "ipranges":[
> {
>"startip":"10.220.164.0",
>"endip":"10.220.164.9",
>"netmask":"255.255.240.0",
>"XRT_GuestIPRangeSize":10,
>"gateway":"10.220.160.1"
> }
>  ],
>  "networktype":"Advanced",
>  "pods":[
> {
>"XRT_PodIPRangeSize":10,
>"name":"XenRT-Zone-0-Pod-0",
>"endip":"10.220.164.39",
>"startip":"10.220.164.30",
>"netmask":"255.255.240.0",
>"clusters":[
>   {
>  "XRT_HyperVHostIds":"0",
>  "clustername":"XenRT-Zone-0-Pod-0-Cluster-0",
>  "hypervisor":"hyperv",
>  "primaryStorages":[
> {
>"url":"cifs://10.220.163.45/storage/primary",
>"name":"XenRT-Zone-0-Pod-0-Primary-Store",
>"details":[
>   {
>  "user":"Administrator"
>   },
>   {
>  "password":"xenroot01T"
>   },
>   {
>  "domain":"XSQA"
>   }
>]
> }
>  ],
>  "clustertype":"CloudManaged",
>  "hosts":[
> {
>"url":"http://10.220.163.45";,
>"username":"root",
>"password":"xenroot"
> }
>  ],
>  "XRT_Hosts":1
>   }
>],
>"gateway":"10.220.160.1"
> }
>  ],
>  "internaldns1":"10.220.160.11",
>  "secondaryStorages":[
> {
>"url":"cifs://10.220.163.45/storage/secondary",
>"details":{
>   "domain":"XSQA",
>   "password":"xenroot01T",
>   "user":"Administrator"
>},
>"provider":"SMB"
>   

Re: Review Request 22500: CLOUDSTACK-6897: In a Multi cluster setup attach of a uploaded volume to a VM on zwps is failing with scope conflict

[Devdeep Singh]

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

Ship it!


Ship It!

- Devdeep Singh


On June 13, 2014, 9:08 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22500/
> ---
> 
> (Updated June 13, 2014, 9:08 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6897
> https://issues.apache.org/jira/browse/CLOUDSTACK-6897
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> when we try to attach the uploaded/allocated volume to a VM on zwps,
>  then we were passing the podId of VM instead of storage pool to storage 
> allocator.
>  This resulting in use of Clusterscope storage allocator, allocating a 
> storage pool for VM on zwps beacuse of pod id not null.
>   This was resulting in scope conflict later
> 
> 
> Diffs
> -
> 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  3cf8c6c 
> 
> Diff: https://reviews.apache.org/r/22500/diff/
> 
> 
> Testing
> ---
> 
> tested by uploading a volume and attaching it to vm on zwps in multi cluster 
> setup
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

Re: Review Request 22500: CLOUDSTACK-6897: In a Multi cluster setup attach of a uploaded volume to a VM on zwps is failing with scope conflict

[ASF Subversion and Git Services]

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


Commit aa21cdcd494aff1df119d2e17a3a51da861e3f51 in cloudstack's branch 
refs/heads/master from Anshul Gangwar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aa21cdc ]

CLOUDSTACK-6897: when we try to attach the uploaded/allocated volume to a VM on 
zwps, then we were passing the podId of VM instead of storage pool to storage 
allocator. This resulting in use of Clusterscope storage allocator, allocating 
a storage pool for VM on zwps beacuse of pod id not null. This was resulting in 
scope conflict later


- ASF Subversion and Git Services


On June 13, 2014, 9:08 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22500/
> ---
> 
> (Updated June 13, 2014, 9:08 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6897
> https://issues.apache.org/jira/browse/CLOUDSTACK-6897
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> when we try to attach the uploaded/allocated volume to a VM on zwps,
>  then we were passing the podId of VM instead of storage pool to storage 
> allocator.
>  This resulting in use of Clusterscope storage allocator, allocating a 
> storage pool for VM on zwps beacuse of pod id not null.
>   This was resulting in scope conflict later
> 
> 
> Diffs
> -
> 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  3cf8c6c 
> 
> Diff: https://reviews.apache.org/r/22500/diff/
> 
> 
> Testing
> ---
> 
> tested by uploading a volume and attaching it to vm on zwps in multi cluster 
> setup
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

Review Request 22554: CLOUDSTACK-6909 - fix marvin's handling of SMB credentials for storage

[John Dilley]

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

Review request for cloudstack.


Bugs: CLOUDSTACK-6909
https://issues.apache.org/jira/browse/CLOUDSTACK-6909


Repository: cloudstack-git


Description
---

Fix marvin's handling of details field for primary and secondary storage to 
cope with SMB credentials. This allows Hyper-V to work.


Diffs
-

  tools/marvin/marvin/deployDataCenter.py 22b78ab 

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


Testing
---

Tested deploydataCenter with this JSON:

{
   "dbSvr":{
  "dbSvr":"10.220.137.39",
  "passwd":"cloud",
  "db":"cloud",
  "port":3306,
  "user":"cloud"
   },
   "zones":[
  {
 "name":"XenRT-Zone-0",
 "guestcidraddress":"192.168.200.0/24",
 "dns1":"10.220.160.11",
 "physical_networks":[
{
   "XRT_VLANRangeSize":10,
   "name":"AdvPhyNetwork",
   "providers":[
  {
 "broadcastdomainrange":"ZONE",
 "name":"VirtualRouter"
  },
  {
 "broadcastdomainrange":"ZONE",
 "name":"VpcVirtualRouter"
  },
  {
 "broadcastdomainrange":"ZONE",
 "name":"InternalLbVm"
  }
   ],
   "broadcastdomainrange":"Zone",
   "vlan":"3000-3009",
   "traffictypes":[
  {
 "typ":"Guest"
  },
  {
 "typ":"Management"
  },
  {
 "typ":"Public"
  }
   ],
   "isolationmethods":[
  "VLAN"
   ]
}
 ],
 "ipranges":[
{
   "startip":"10.220.164.0",
   "endip":"10.220.164.9",
   "netmask":"255.255.240.0",
   "XRT_GuestIPRangeSize":10,
   "gateway":"10.220.160.1"
}
 ],
 "networktype":"Advanced",
 "pods":[
{
   "XRT_PodIPRangeSize":10,
   "name":"XenRT-Zone-0-Pod-0",
   "endip":"10.220.164.39",
   "startip":"10.220.164.30",
   "netmask":"255.255.240.0",
   "clusters":[
  {
 "XRT_HyperVHostIds":"0",
 "clustername":"XenRT-Zone-0-Pod-0-Cluster-0",
 "hypervisor":"hyperv",
 "primaryStorages":[
{
   "url":"cifs://10.220.163.45/storage/primary",
   "name":"XenRT-Zone-0-Pod-0-Primary-Store",
   "details":[
  {
 "user":"Administrator"
  },
  {
 "password":"xenroot01T"
  },
  {
 "domain":"XSQA"
  }
   ]
}
 ],
 "clustertype":"CloudManaged",
 "hosts":[
{
   "url":"http://10.220.163.45";,
   "username":"root",
   "password":"xenroot"
}
 ],
 "XRT_Hosts":1
  }
   ],
   "gateway":"10.220.160.1"
}
 ],
 "internaldns1":"10.220.160.11",
 "secondaryStorages":[
{
   "url":"cifs://10.220.163.45/storage/secondary",
   "details":{
  "domain":"XSQA",
  "password":"xenroot01T",
  "user":"Administrator"
   },
   "provider":"SMB"
}
 ]
  }
   ],
   "mgtSvr":[
  {
 "mgtSvrIp":"10.220.137.39",
 "passwd":"xenroot",
 "port":8096,
 "user":"root"
  }
   ]
}


Thanks,

John Dilley

Re: Review Request 22414: CLOUDSTACK-6865, CLOUDSTACK-6868: [hyper-v] attach volume of vhd format volume is failing

[Devdeep Singh]

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

Ship it!


Ship It!

- Devdeep Singh


On June 10, 2014, 11:23 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22414/
> ---
> 
> (Updated June 10, 2014, 11:23 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6865 and CLOUDSTACK-6868
> https://issues.apache.org/jira/browse/CLOUDSTACK-6865
> https://issues.apache.org/jira/browse/CLOUDSTACK-6868
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> while attaching the volume we were changing the volume's Image format to 
> hypervisor's default Image format, hence it was failing to find the volume 
> with vhdx format
> Now changed the behavior to set Image Format for volume only when it is 
> not set
> 
> 
> Diffs
> -
> 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  064ffca 
> 
> Diff: https://reviews.apache.org/r/22414/diff/
> 
> 
> Testing
> ---
> 
> verified by uploading the vhd volume and attaching it to VM
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

Re: Review Request 22452: CLOUDSTACK-6872 : removed the redundant connectToRemote method

[Devdeep Singh]

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

Ship it!


Ship It!

- Devdeep Singh


On June 11, 2014, 7:31 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22452/
> ---
> 
> (Updated June 11, 2014, 7:31 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6872
> https://issues.apache.org/jira/browse/CLOUDSTACK-6872
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Removed the redundant connectTORemote method in Hyper-v Agent. We dont't need 
> this method as share is domain joined so it has all the required permissions. 
> Removal of this method fixes this bug also.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/HypervResourceController.cs
>  0ad95b8 
>   plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/Utils.cs 
> c8e951e 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/WmiCallsV2.cs 
> 372f848 
> 
> Diff: https://reviews.apache.org/r/22452/diff/
> 
> 
> Testing
> ---
> 
> tested that volume operations are working fine after removal of this method
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

Re: Review Request 22415: CLOUDSTACK-6867: added the option for vhdx image format in upload volume

[Devdeep Singh]

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

Ship it!


Ship It!

- Devdeep Singh


On June 11, 2014, 5:20 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22415/
> ---
> 
> (Updated June 11, 2014, 5:20 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6867
> https://issues.apache.org/jira/browse/CLOUDSTACK-6867
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> added the option for vhdx image format in upload volume
> 
> 
> Diffs
> -
> 
>   ui/scripts/storage.js 604f09d 
> 
> Diff: https://reviews.apache.org/r/22415/diff/
> 
> 
> Testing
> ---
> 
> verified by opening the upload volume dialog in UI
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

Re: Review Request 22500: CLOUDSTACK-6897: In a Multi cluster setup attach of a uploaded volume to a VM on zwps is failing with scope conflict

[Anshul Gangwar]

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

(Updated June 13, 2014, 9:08 a.m.)


Review request for cloudstack, Devdeep Singh and Rajesh Battala.


Changes
---

updated patch for master


Bugs: CLOUDSTACK-6897
https://issues.apache.org/jira/browse/CLOUDSTACK-6897


Repository: cloudstack-git


Description
---

when we try to attach the uploaded/allocated volume to a VM on zwps,
 then we were passing the podId of VM instead of storage pool to storage 
allocator.
 This resulting in use of Clusterscope storage allocator, allocating a storage 
pool for VM on zwps beacuse of pod id not null.
  This was resulting in scope conflict later


Diffs (updated)
-

  
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
 3cf8c6c 

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


Testing
---

tested by uploading a volume and attaching it to vm on zwps in multi cluster 
setup


Thanks,

Anshul Gangwar

Re: [DISCUSS] 4.3.1

[ilya musayev]

Sebastian,

Please disregard the revert request,

Thanks,
ilya

On 6/12/14, 5:55 PM, ilya musayev wrote:

Sebastian,

Please cherry-pick following commits:

CLOUDSTACK-5891.[VMware] If a template has been registered and 
"cpu.corespersocket...
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=008b029a29460d883ac7d645877e6f4f2945b1e1 



CLOUDSTACK-6317 [VMware] Tagged VLAN support broken for 
Management/Control/Storage traffic
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=5bc72ea25000456b4a479baac8f9e0690794c0d2 



CLOUDSTACK-6478: Failed to download Template when having 3 SSVM's in 
one zone on Vmware.
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=8e286996c8cdb58255a631b3bd977ad4b4baebd2 



I would ask if we can revert not so useful functionality that actually 
makes cloudstack very inflexible:

https://issues.apache.org/jira/browse/CLOUDSTACK-3911
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=a3b1a49c303a929c754561ca07fd8a9ed84e0382 



Thanks
ilya

PS: In the next week or two, i should have a lighter work load and 
willing to help with testing or whatever else you may need to help with.



On 6/12/14, 7:17 AM, sebgoa wrote:

While we are talking about 4.4

I am game to RM a 4.3.1 , there has been several bug fixes since 4.3.0.

Anybody interested, any suggestions of what would still need to be 
cherry picked ?


https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.3 



-Sebastien

Re: Review Request 22414: CLOUDSTACK-6865, CLOUDSTACK-6868: [hyper-v] attach volume of vhd format volume is failing

[ASF Subversion and Git Services]

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


Commit 66d1eb92f03c39734dcaf83e20639cd9a338e388 in cloudstack's branch 
refs/heads/master from Anshul Gangwar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=66d1eb9 ]

CLOUDSTACK-6865 , CLOUDSTACK-6868: [hyperv] while attaching the volume we were 
changing the volume's Image format to hypervisor's default Image format, hence 
it was failing to find the volume with vhdx format. Now changed the behavior to 
set Image Format for volume only when it is not set


- ASF Subversion and Git Services


On June 10, 2014, 11:23 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22414/
> ---
> 
> (Updated June 10, 2014, 11:23 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6865 and CLOUDSTACK-6868
> https://issues.apache.org/jira/browse/CLOUDSTACK-6865
> https://issues.apache.org/jira/browse/CLOUDSTACK-6868
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> while attaching the volume we were changing the volume's Image format to 
> hypervisor's default Image format, hence it was failing to find the volume 
> with vhdx format
> Now changed the behavior to set Image Format for volume only when it is 
> not set
> 
> 
> Diffs
> -
> 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  064ffca 
> 
> Diff: https://reviews.apache.org/r/22414/diff/
> 
> 
> Testing
> ---
> 
> verified by uploading the vhd volume and attaching it to VM
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

Re: Review Request 22452: CLOUDSTACK-6872 : removed the redundant connectToRemote method

[ASF Subversion and Git Services]

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


Commit b43036d10e718eea869574780e8ad70b18862b16 in cloudstack's branch 
refs/heads/master from Anshul Gangwar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b43036d ]

CLOUDSTACK-6872: [hyperv] removed the redundant connectToRemote, 
DisconnectRemote methods which in turn fixes this bug. connectToRemote was used 
to connect to share, but once the share is domain joined we don't need this 
method as we already have required permissions


- ASF Subversion and Git Services


On June 11, 2014, 7:31 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22452/
> ---
> 
> (Updated June 11, 2014, 7:31 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6872
> https://issues.apache.org/jira/browse/CLOUDSTACK-6872
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Removed the redundant connectTORemote method in Hyper-v Agent. We dont't need 
> this method as share is domain joined so it has all the required permissions. 
> Removal of this method fixes this bug also.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/HypervResourceController.cs
>  0ad95b8 
>   plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/Utils.cs 
> c8e951e 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/WmiCallsV2.cs 
> 372f848 
> 
> Diff: https://reviews.apache.org/r/22452/diff/
> 
> 
> Testing
> ---
> 
> tested that volume operations are working fine after removal of this method
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

Re: Review Request 22415: CLOUDSTACK-6867: added the option for vhdx image format in upload volume

[ASF Subversion and Git Services]

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


Commit 7ea3930ae9770c2c52749de9a523f007b80d8b24 in cloudstack's branch 
refs/heads/master from Anshul Gangwar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7ea3930 ]

CLOUDSTACK-6867: Added option to upload the volume in VHDX format


- ASF Subversion and Git Services


On June 11, 2014, 5:20 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22415/
> ---
> 
> (Updated June 11, 2014, 5:20 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6867
> https://issues.apache.org/jira/browse/CLOUDSTACK-6867
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> added the option for vhdx image format in upload volume
> 
> 
> Diffs
> -
> 
>   ui/scripts/storage.js 604f09d 
> 
> Diff: https://reviews.apache.org/r/22415/diff/
> 
> 
> Testing
> ---
> 
> verified by opening the upload volume dialog in UI
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

Re: Review Request 22414: CLOUDSTACK-6865, CLOUDSTACK-6868: [hyper-v] attach volume of vhd format volume is failing

[ASF Subversion and Git Services]

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


Commit 66d1eb92f03c39734dcaf83e20639cd9a338e388 in cloudstack's branch 
refs/heads/master from Anshul Gangwar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=66d1eb9 ]

CLOUDSTACK-6865 , CLOUDSTACK-6868: [hyperv] while attaching the volume we were 
changing the volume's Image format to hypervisor's default Image format, hence 
it was failing to find the volume with vhdx format. Now changed the behavior to 
set Image Format for volume only when it is not set


- ASF Subversion and Git Services


On June 10, 2014, 11:23 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22414/
> ---
> 
> (Updated June 10, 2014, 11:23 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6865 and CLOUDSTACK-6868
> https://issues.apache.org/jira/browse/CLOUDSTACK-6865
> https://issues.apache.org/jira/browse/CLOUDSTACK-6868
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> while attaching the volume we were changing the volume's Image format to 
> hypervisor's default Image format, hence it was failing to find the volume 
> with vhdx format
> Now changed the behavior to set Image Format for volume only when it is 
> not set
> 
> 
> Diffs
> -
> 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  064ffca 
> 
> Diff: https://reviews.apache.org/r/22414/diff/
> 
> 
> Testing
> ---
> 
> verified by uploading the vhd volume and attaching it to VM
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

Re: FindBugs report disabled ?

[Daan Hoogland]

I disabled it as it did no longer give output on where new issues were
found. I started building a new job called master-slowbuild. It is not
fully functional and it slipped my mind.

there is non for 4.4

On Fri, Jun 13, 2014 at 12:06 AM, Rayees Namathponnan
 wrote:
> Hi,
>
> I am looking for FindBugs report in jenkis  
> http://jenkins.buildacloud.org/job/build-master-slowbuild/ ; looks like its 
> disabled from May 21 , any idea about this ?
>
> Is there FindBugs reported scheduled for 4.4 branch?
>
> Regards,
> Rayees



-- 
Daan

[ACS44] moving issues to 4.5

[Daan Hoogland]

tagging the subject

On Fri, Jun 13, 2014 at 10:18 AM, Daan Hoogland  wrote:
> On Thu, Jun 12, 2014 at 11:12 PM, Animesh Chaturvedi
>  wrote:
>>> [Animesh] Every release has a filter for new features and improvements.
>>> Here is one for 4.4 that I had setup a while back
>>> https://issues.apache.org/jira/issues/?filter=12326986
>> [Animesh] 9 of these issues are still open and I sent BULK EDIT reminder to 
>> move them out.
>
> Along the lines of what Animesh sugested but slightly more radical, I
> will move features that were scheduled for 4.4 out to 'future' in a
> couple.. Feel free to move them back in if they are ready and in the
> 4.4 source base already. This is just a jira action.
>
> regards
> --
> Daan



-- 
Daan

moving issues to 4.5

[Daan Hoogland]

On Thu, Jun 12, 2014 at 11:12 PM, Animesh Chaturvedi
 wrote:
>> [Animesh] Every release has a filter for new features and improvements.
>> Here is one for 4.4 that I had setup a while back
>> https://issues.apache.org/jira/issues/?filter=12326986
> [Animesh] 9 of these issues are still open and I sent BULK EDIT reminder to 
> move them out.

Along the lines of what Animesh sugested but slightly more radical, I
will move features that were scheduled for 4.4 out to 'future' in a
couple.. Feel free to move them back in if they are ready and in the
4.4 source base already. This is just a jira action.

regards
-- 
Daan

Re: hackathon CCCEU14

[Daan Hoogland]

kocka, go ahead and edit (though you can't work on all of those
subjects during the hackathon, hope you realize that)

On Thu, Jun 12, 2014 at 7:46 PM, Laszlo Hornyak
 wrote:
> Hi,
>
> Could you give me write permission to the wiki? Or you can just add me to
> the wikipage, I will want to work a little bit on all of those :)
>
> Thank you,
> Laszlo
>
>
> On Tue, Jun 10, 2014 at 2:35 PM, Daan Hoogland 
> wrote:
>
>> Hello everybody,
>>
>> Do we still want to have a Hackathon next CCC? we need to plan for the
>> resources (noticably the room) pretty soon.
>>
>> On Thu, Jun 5, 2014 at 12:01 PM, Daan Hoogland
>>  wrote:
>> > People,
>> >
>> > I added two more hackathon subjects at
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Collaboration+Conference+EU
>> > In doing so I saw no moderators on the hackathons that were already
>> announced. We need moderators to have successful hackathons. If  you feel a
>> hackathon subject is important enough to go through, please add your name
>> in the wiki. Only hackathons with enough attendance will have resources
>> assigned at the conference.
>> >
>> > \DaanH
>> >
>>
>>
>>
>> --
>> Daan
>>
>
>
>
> --
>
> EOF



-- 
Daan

Review Request 22549: CLOUDSTACK-6887: Fixing account cleanup issue across multiple test cases

[Gaurav Aradhye]

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

Review request for cloudstack and Girish Shilamkar.


Bugs: CLOUDSTACK-6887
https://issues.apache.org/jira/browse/CLOUDSTACK-6887


Repository: cloudstack-git


Description
---

Fixing account cleanup issues across multiple test cases. This patch contains 
test cases fixes in 8 test suites. Will put up new patch for remaining test 
suites as and when I fix them.


Diffs
-

  test/integration/component/test_add_remove_network.py 20aefe4 
  test/integration/component/test_persistent_networks.py ab1e2c2 
  test/integration/component/test_projects.py c593fb6 
  test/integration/component/test_snapshot_gc.py 42c361c 
  test/integration/component/test_snapshot_limits.py 95c6432 
  test/integration/component/test_usage.py 03823be 
  test/integration/component/test_volumes.py b5b08e2 
  test/integration/smoke/test_affinity_groups.py 4f3f9ec 

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


Testing
---

Tested on VMware.


Thanks,

Gaurav Aradhye

Re: Review Request 22414: CLOUDSTACK-6865, CLOUDSTACK-6868: [hyper-v] attach volume of vhd format volume is failing

[ASF Subversion and Git Services]

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


Commit ebff469b46551f8613013e80aa0386203a9c7912 in cloudstack's branch 
refs/heads/4.4-forward from Anshul Gangwar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ebff469 ]

CLOUDSTACK-6865 , CLOUDSTACK-6868: [hyperv] while attaching the volume we were 
changing the volume's Image format to hypervisor's default Image format, hence 
it was failing to find the volume with vhdx format. Now changed the behavior to 
set Image Format for volume only when it is not set


- ASF Subversion and Git Services


On June 10, 2014, 11:23 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22414/
> ---
> 
> (Updated June 10, 2014, 11:23 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6865 and CLOUDSTACK-6868
> https://issues.apache.org/jira/browse/CLOUDSTACK-6865
> https://issues.apache.org/jira/browse/CLOUDSTACK-6868
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> while attaching the volume we were changing the volume's Image format to 
> hypervisor's default Image format, hence it was failing to find the volume 
> with vhdx format
> Now changed the behavior to set Image Format for volume only when it is 
> not set
> 
> 
> Diffs
> -
> 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  064ffca 
> 
> Diff: https://reviews.apache.org/r/22414/diff/
> 
> 
> Testing
> ---
> 
> verified by uploading the vhd volume and attaching it to VM
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

Re: Review Request 22500: CLOUDSTACK-6897: In a Multi cluster setup attach of a uploaded volume to a VM on zwps is failing with scope conflict

[ASF Subversion and Git Services]

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


Commit 2dc9e2c530b36efc4c4684e13ae0412103925d05 in cloudstack's branch 
refs/heads/4.4-forward from Anshul Gangwar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2dc9e2c ]

CLOUDSTACK-6897: when we try to attach the uploaded/allocated volume to a VM on 
zwps, then we were passing the podId of VM instead of storage pool to storage 
allocator. This resulting in use of Clusterscope storage allocator, allocating 
a storage pool for VM on zwps beacuse of pod id not null. This was resulting in 
scope conflict later


- ASF Subversion and Git Services


On June 12, 2014, 8:36 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22500/
> ---
> 
> (Updated June 12, 2014, 8:36 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6897
> https://issues.apache.org/jira/browse/CLOUDSTACK-6897
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> when we try to attach the uploaded/allocated volume to a VM on zwps,
>  then we were passing the podId of VM instead of storage pool to storage 
> allocator.
>  This resulting in use of Clusterscope storage allocator, allocating a 
> storage pool for VM on zwps beacuse of pod id not null.
>   This was resulting in scope conflict later
> 
> 
> Diffs
> -
> 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  5bc788e 
> 
> Diff: https://reviews.apache.org/r/22500/diff/
> 
> 
> Testing
> ---
> 
> tested by uploading a volume and attaching it to vm on zwps in multi cluster 
> setup
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

Re: Review Request 22415: CLOUDSTACK-6867: added the option for vhdx image format in upload volume

[ASF Subversion and Git Services]

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


Commit 2e49ef73bfcb548cf19d1230f00a0510b7d09150 in cloudstack's branch 
refs/heads/4.4-forward from Anshul Gangwar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2e49ef7 ]

CLOUDSTACK-6867: Added option to upload the volume in VHDX format


- ASF Subversion and Git Services


On June 11, 2014, 5:20 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22415/
> ---
> 
> (Updated June 11, 2014, 5:20 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6867
> https://issues.apache.org/jira/browse/CLOUDSTACK-6867
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> added the option for vhdx image format in upload volume
> 
> 
> Diffs
> -
> 
>   ui/scripts/storage.js 604f09d 
> 
> Diff: https://reviews.apache.org/r/22415/diff/
> 
> 
> Testing
> ---
> 
> verified by opening the upload volume dialog in UI
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

Re: Review Request 22452: CLOUDSTACK-6872 : removed the redundant connectToRemote method

[ASF Subversion and Git Services]

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


Commit cef29948a708fbbae1261dbd8b6a13e4da19c703 in cloudstack's branch 
refs/heads/4.4-forward from Anshul Gangwar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=cef2994 ]

CLOUDSTACK-6872: [hyperv] removed the redundant connectToRemote, 
DisconnectRemote methods which in turn fixes this bug. connectToRemote was used 
to connect to share, but once the share is domain joined we don't need this 
method as we already have required permissions


- ASF Subversion and Git Services


On June 11, 2014, 7:31 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22452/
> ---
> 
> (Updated June 11, 2014, 7:31 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6872
> https://issues.apache.org/jira/browse/CLOUDSTACK-6872
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Removed the redundant connectTORemote method in Hyper-v Agent. We dont't need 
> this method as share is domain joined so it has all the required permissions. 
> Removal of this method fixes this bug also.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/HypervResourceController.cs
>  0ad95b8 
>   plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/Utils.cs 
> c8e951e 
>   
> plugins/hypervisors/hyperv/DotNet/ServerResource/HypervResource/WmiCallsV2.cs 
> 372f848 
> 
> Diff: https://reviews.apache.org/r/22452/diff/
> 
> 
> Testing
> ---
> 
> tested that volume operations are working fine after removal of this method
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>

Re: Review Request 22414: CLOUDSTACK-6865, CLOUDSTACK-6868: [hyper-v] attach volume of vhd format volume is failing

[ASF Subversion and Git Services]

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


Commit ebff469b46551f8613013e80aa0386203a9c7912 in cloudstack's branch 
refs/heads/4.4-forward from Anshul Gangwar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ebff469 ]

CLOUDSTACK-6865 , CLOUDSTACK-6868: [hyperv] while attaching the volume we were 
changing the volume's Image format to hypervisor's default Image format, hence 
it was failing to find the volume with vhdx format. Now changed the behavior to 
set Image Format for volume only when it is not set


- ASF Subversion and Git Services


On June 10, 2014, 11:23 a.m., Anshul Gangwar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22414/
> ---
> 
> (Updated June 10, 2014, 11:23 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6865 and CLOUDSTACK-6868
> https://issues.apache.org/jira/browse/CLOUDSTACK-6865
> https://issues.apache.org/jira/browse/CLOUDSTACK-6868
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> while attaching the volume we were changing the volume's Image format to 
> hypervisor's default Image format, hence it was failing to find the volume 
> with vhdx format
> Now changed the behavior to set Image Format for volume only when it is 
> not set
> 
> 
> Diffs
> -
> 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  064ffca 
> 
> Diff: https://reviews.apache.org/r/22414/diff/
> 
> 
> Testing
> ---
> 
> verified by uploading the vhd volume and attaching it to VM
> 
> 
> Thanks,
> 
> Anshul Gangwar
> 
>