Re: Maximum template upload size

[Tejas Gadaria]

Thanks this resolved the issue.

Regards,
Tejas


On Mon, Jun 30, 2014 at 9:44 AM, Abhinandan Prateek <
abhinandan.prat...@citrix.com> wrote:

> max.template.iso.size global param defines the max size for template
> upload.
>
>
> On 28/06/14 12:53 pm, "Tejas Gadaria"  wrote:
>
> >Hi
> >
> >What is the maximum size of template we can upload to secondary storage
> >through "register template" using http ?
> >
> >Regards,
> >Tejas
>
>

Re: how we can disable process/scheduler which delete the vms from hyper-wiser if that vms info are not available in database.?

[chandraprakash mishra]

thanks for replied to me.

earlier i  was using 4.2
Now upgraded with 4.3


On Mon, Jun 30, 2014 at 10:52 AM, Suresh Sadhu 
wrote:

> Earlier it used to delete the vms created outside of cloudstack during
> vmsync and with new vmsync changes introduced ,vmsync identifies vms
> created outside and will ignore.it won't delete.
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+VMSync+improvement
>
> As Abhi said these changes  should be in master.
>
> Regards
> Sadhu
>
>
> -Original Message-
> From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
> Sent: 30 June 2014 09:31
> To: dev@cloudstack.apache.org
> Subject: Re: how we can disable process/scheduler which delete the vms
> from hyper-wiser if that vms info are not available in database.?
>
> What version have you seen the sync removing non cloudstack Vms ?
> As per my knowledge this should not happen in master.
>
> -abhi
>
> On 28/06/14 12:53 am, "chandraprakash mishra" 
> wrote:
>
> >Hello,
> >As i know in CS there is a process/scheduler  is running which delete
> >the vms from hyper-wiser( xen host) if that vms info are not available
> >in database.
> >how we can disable this service/scheduler for some time.
> >
> >--
> >Thanks and Regards,
> >cpm
>
>


-- 
Thanks and Regards,
Chandra Prakash Mishra
Software engineer,hp
9611424996

Review Request 23150: CLOUDSTACK-7006: Restore template ID in ROOT volume usages

[Olivier Lemasle]

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

Review request for cloudstack, Kishan Kavala and Sebastien Goasguen.


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


Repository: cloudstack-git


Description
---

This patch restore the template ID in usages, for ROOT volume created from a 
template (see CLOUDSTACK-7006).

The regression was on the class com.cloud.storage.VolumeManagerImpl (module 
"cloud-server") but it has been renamed 
org.apache.cloudstack.engine.orchestration.VolumeOrchestrator (module 
"cloud-engine-orchestration").

The patch applies on branchs master and branch 4.4.
I've attached another patch for branch 4.3 (the only difference is formatting).


Diffs
-

  
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
 9ba3451 

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


Testing
---

Tested in ACS 4.3.
1. Deploy a new VM from a template.
2. Check if usages for the ROOT volume has the right templateId.
3. Deploy a new VM from an ISO, and add a DATA volume.
4. Check that there is no regression for these two types of volume usages 
without templateId.


File Attachments


patch version for ACS 4.3
  
https://reviews.apache.org/media/uploaded/files/2014/06/29/eee8a901-4141-46e7-b4ce-d9cbcfd8c85f__cloudstack-7006-for-ACS4.3.patch


Thanks,

Olivier Lemasle

[ACS4.4] RC1

[Daan Hoogland]

This is going to be the vote thread but I read back the procedure and
found that I should more explicitly ask for consent before starting
the vote.

162ea957e6f02e56f2de7a639f4c7e593b1b3e72 is the commit id for the
version I would like to release. Do we have the feeling that this is a
version stable enough?

More specific: Citrix QA, do you have a good confidence level with the
present state of the 4.4 branch?

kind regards,
-- 
Daan

[ACS43] upgrade for vlan uris

[Daan Hoogland]

Sebastien,

I just made a port of the vlan uri data migration to the 4.3 branch
and java 6, in a 430to431 class and am about to commit/push. Do you
plan to have a quality check on this? I do not have the problem myself
so maybe someone that did/has should test it.

-- 
Daan

Re: [ACS-Master] Cannot load compute offerings: NPE

[Sonal Ojha]

With the changes in master a new entry "Off" got introduced in the disk
offering table which made things to break.

The database entries for provisioning_type in the disk_offering_view table
shows "Off"

mysql> select provisioning_type from disk_offering_view;
+---+
| provisioning_type |
+---+
| Off   |
| Off   |
| thin  |
| thin  |
| thin  |
| thin  |
| thin  |
| thin  |
| thin  |
| thin  |
| thin  |
| thin  |
| thin  |
+---+
13 rows in set (0.00 sec)

Change the provisioning_type to *thin (provisioning_type can only have
values as thin, fat, sparse) *and things works fine.

Was this new value introduced for a purpose ??


On Thu, Jun 19, 2014 at 12:06 PM, Wilder Rodrigues <
wrodrig...@schubergphilis.com> wrote:

> I have a clean environment, just created 2 VPCs. Before that, DB and
> everything was cleaned up and built based on the latest code.
>
> I will have a look in the code, then.
>
> Cheers,
> Wilder
>
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: woensdag 18 juni 2014 5:22
> To: dev@cloudstack.apache.org
> Cc: int-toolkit
> Subject: Re: [ACS-Master] Cannot load compute offerings: NPE
>
> I noticed a similar issue yesterday when trying to retrieve a list of
> storage volumes.
>
> I was planning on building everything up from scratch again (including the
> DB) to repro the issue to see if it's gone now, but it looks like it might
> be a more wide-spread problem than what I was just seeing.
>
> On Wed, Jun 18, 2014 at 8:07 AM, Wilder Rodrigues <
> wrodrig...@schubergphilis.com>
> wrote:
> Hi guys,
>
> I'm facing a problem when loading service offerings on ACS Master branch.
> Is anyone aware of this? Is there any issue open?
>
> 2014-06-18 15:54:52,495 DEBUG [c.c.a.ApiServlet] 
> (19418424@qtp-9894122-6:ctx-3a0f1094)
> ===START===  0:0:0:0:0:0:0:1 -- GET  command=listServ
>
> iceOfferings&response=json&sessionkey=pzJwAgN95saj%2FfExWkezaytg7U4%3D&listAll=true&page=1&pagesize=20&issystem=false&_=1403099692481
> 2014-06-18 15:54:52,608 WARN  [c.c.a.d.ParamGenericValidationWorker]
> (19418424@qtp-9894122-6:ctx-3a0f1094 ctx-226b1105) Received unknown par
> ameters for command listServiceOfferings. Unknown parameters : listall
> 2014-06-18 15:54:52,710 ERROR [c.c.a.ApiServer] 
> (19418424@qtp-9894122-6:ctx-3a0f1094
> ctx-226b1105) unhandled exception executing api command
> : [Ljava.lang.String;@fd06cb
> java.lang.NullPointerException
> at
> com.cloud.api.query.dao.ServiceOfferingJoinDaoImpl.newServiceOfferingResponse(ServiceOfferingJoinDaoImpl.java:62)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
> at
> com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
> at com.sun.proxy.$Proxy270.newServiceOfferingResponse(Unknown
> Source)
> at
> com.cloud.api.ApiDBUtils.newServiceOfferingResponse(ApiDBUtils.java:1794)
> at
> com.cloud.api.query.ViewResponseHelper.createServiceOfferingResponse(ViewResponseHelper.java:354)
> at
> com.cloud.api.query.QueryManagerImpl.searchForServiceOfferings(QueryManagerImpl.java:2415)
> at
> org.apache.cloudstack.api.command.user.offering.ListServiceOfferingsCmd.execute(ListServiceOfferingsCmd.java:106)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
> at com.cloud.api.ApiServer.queueCommand(ApiServer.java:689)
> at com.cloud.api.ApiServer.handleRequest(ApiServer.java:512)
> at
> com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317)
> at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
> at
> org.apache.cloudstack.managed.context.impl.DefaultManagedContext$

Re: Review Request 23009: Fix for test_portable_ip.py script issues

[SrikanteswaraRao Talluri]

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



test/integration/component/test_portable_ip.py


Instead to this, can you modify the services() dictionary or move all the 
data in the services dictionary into test_data.py


- SrikanteswaraRao Talluri


On June 26, 2014, 11:55 a.m., sanjeev n wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23009/
> ---
> 
> (Updated June 26, 2014, 11:55 a.m.)
> 
> 
> Review request for cloudstack, Santhosh Edukulla and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CS-6992
> https://issues.apache.org/jira/browse/CS-6992
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> 1.Currently the test is not reading test data from the config file. So I have 
> made changes in the script to read test data and use it in all the test 
> methods
> 2.Reading portable ip config values was not proper in 
> getPortableIpRangeServices in lib/common.py so made changes in the library to 
> read portable ip values properly
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_portable_ip.py b9c9059 
>   tools/marvin/marvin/lib/common.py 7b0c7ad 
> 
> Diff: https://reviews.apache.org/r/23009/diff/
> 
> 
> Testing
> ---
> 
> Yes
> 
> 
> Thanks,
> 
> sanjeev n
> 
>

[QUERY] CLOUDSTACK-6885 Rsyslog not rotating

[Sonal Ojha]

Hello,

I am seeing similar issue of rsyslog not rotating on the systemvm.

I tried replacing the reload with rotate in the invoke-rc.d, but it didnt
seem to work. The only way I could make it work was by the following command

logrotate -f /etc/logrotate.d/rsyslog

Can you help to know if modifying the invoke-rc.d worked as expected.

-- 

*Thanks and Regards,*

*Sonal Ojha ▪ Sr.Engineer - Product Development **▪ **Sungard Availability
Services, India*

2nd Floor, Wing 4, Cluster D, MIDC Kharadi Knowledge Park, Pune - 411 014 ▪
Office: 267-234-9014 ▪ Mobile: +91 9922412645 ▪ sonal.o...@sungardas.com ▪
www.sungardas. *in*

*[image: Logo]* 
*[image: cid:image019.png@01CF48EC.6617C7F0]*
 *[image:
cid:image020.png@01CF48EC.6617C7F0]* 
 *[image: cid:image021.png@01CF48EC.6617C7F0]*
 *[image:
cid:image022.png@01CF48EC.6617C7F0]*
 *[image:
cid:image023.png@01CF48EC.6617C7F0]*
 *[image:
cid:image024.png@01CF48EC.6617C7F0]* 
*CONFIDENTIALITY:*  This e-mail (including any attachments) may contain
confidential, proprietary and privileged information, and unauthorized
disclosure or use is prohibited.  If you received this e-mail in error,
please notify the sender and delete this e-mail from your system.

Re: Review Request 22928: Fixed resource leaks and added support for secstoragefirewallcfg command to simulator in master

[Santhosh Edukulla]

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

Ship it!


Ship It!

- Santhosh Edukulla


On June 24, 2014, 6:06 p.m., Santhosh Edukulla wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22928/
> ---
> 
> (Updated June 24, 2014, 6:06 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and daan Hoogland.
> 
> 
> Bugs: coverity
> https://issues.apache.org/jira/browse/coverity
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> 1. Fixed few Resource Leaks reported by coverity in master
> 2. As well added support for a config command to simulator in master
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/upgrade/dao/DatabaseAccessObject.java 836a537 
>   framework/db/src/com/cloud/utils/crypt/EncryptionSecretKeyChanger.java 
> 4cee081 
>   framework/db/src/com/cloud/utils/db/ScriptRunner.java 932b37b 
>   
> plugins/hypervisors/simulator/src/com/cloud/agent/manager/SimulatorManagerImpl.java
>  321f06f 
> 
> Diff: https://reviews.apache.org/r/22928/diff/
> 
> 
> Testing
> ---
> 
> Built the simulator code and deployed a datacenter
> 
> 
> Thanks,
> 
> Santhosh Edukulla
> 
>

[ACS-4.4] cherry-pick

[Jayapal Reddy Uradi]

Hi Daan,

Can you please cherry pick the below commit to 4.4

commit 004d616322ba55d83407545f5b10c95ce48f75b5
CLOUDSTACK-6997: Increase proc ip_conntrack_max

Thanks,
Jayapal

Re: [ACS4.4] RC1

[Ove Ewerlid]

On 06/30/2014 11:23 AM, Daan Hoogland wrote:

This is going to be the vote thread but I read back the procedure and
found that I should more explicitly ask for consent before starting
the vote.

162ea957e6f02e56f2de7a639f4c7e593b1b3e72 is the commit id for the
version I would like to release. Do we have the feeling that this is a
version stable enough?

More specific: Citrix QA, do you have a good confidence level with the
present state of the 4.4 branch?

kind regards,



My build script experience an issue when building versus the 4.4 RC1 
commit id. The script works with "git checkout 4.4" but when doing "git 
checkout " below issue occurs. The only difference (right 
now) is changing "4.4-SNAPSHOT" --> "4.4.0" throughout the tree.


This Warning is issued;
[INFO] Building Apache CloudStack Maven Conventions Parent 4.4.0
[INFO] 


[INFO]
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-maven-standard ---
[WARNING] The POM for org.apache.cloudstack:checkstyle:jar:4.4.0 is 
missing, no dependency information available


Then build errors out with;

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check 
(cloudstack-checkstyle) on project cloud-maven-standard: Execution 
cloudstack-checkstyle of goal 
org.apache.maven.plugins:maven-checkstyle-plugin\
:2.11:check failed: Plugin 
org.apache.maven.plugins:maven-checkstyle-plugin:2.11 or one of its 
dependencies could not be resolved: Failure to find 
org.apache.cloudstack:checkstyle:jar:4.4.0 in 
http://repo.maven.apache.org/maven2 was cac\
hed in the local repository, resolution will not be reattempted until 
the update interval of central has elapsed or updates are forced -> [Help 1]


A usual suspect is the Maven M2 cache, the same error happens when 
building from clean cache and when building on top of a successful 4.4 
build that populates a cache sufficient for 4.4. Some 10 attempts tried, 
the same issue each time. This is with Maven v3.2.1. Build host is OEL65 
with latest updates (e.g., effectively RHEL65).


The build script handles 4.3, 4.3.0 and 4.4 without issues, just tested 
that.


Thoughts?

/Ove


--
Ove Everlid
System Administrator / Architect / SDN- & Automation- & Linux-hacker
Mobile: +46706668199 (dedicated work mobile)
Country: Sweden, timezone; Middle Europan Time (MET or GMT+1)

Re: Review Request 22927: Bugfix CLOUDSTACK-6261: remove the forceful timeout setting when login to NetScaler.

[Rajesh Battala]

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



plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java


Remove the timeout from this method also
This fix should have thrown compilation error as the variable not found.

After fixing it Please build the code and post it for review.



- Rajesh Battala


On June 24, 2014, 10:23 a.m., Sujaya Maiyya wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22927/
> ---
> 
> (Updated June 24, 2014, 10:23 a.m.)
> 
> 
> Review request for cloudstack, Murali Reddy and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6261
> https://issues.apache.org/jira/browse/CLOUDSTACK-6261
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The NetScaler Resource forces a idle timeout of 100,000 seconds during login. 
> It is best to leave it to the system default which is 30 mins. The timeout 
> has been removed from NetscalerResource in order to support login for 
> Netscaler 10.5 devices.
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
>  54e5d50 
> 
> Diff: https://reviews.apache.org/r/22927/diff/
> 
> 
> Testing
> ---
> 
> Timeout was removed and login to the Netscaler devices with the default 
> timeout of 30 minutes was successful. It was tested for Netscaler builds 10.1 
> and 10.5.
> 
> 
> Thanks,
> 
> Sujaya Maiyya
> 
>

Re: Review Request 22927: Bugfix CLOUDSTACK-6261: remove the forceful timeout setting when login to NetScaler.

[Rajesh Battala]

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

Ship it!


Ship It!

- Rajesh Battala


On June 24, 2014, 10:23 a.m., Sujaya Maiyya wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22927/
> ---
> 
> (Updated June 24, 2014, 10:23 a.m.)
> 
> 
> Review request for cloudstack, Murali Reddy and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6261
> https://issues.apache.org/jira/browse/CLOUDSTACK-6261
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The NetScaler Resource forces a idle timeout of 100,000 seconds during login. 
> It is best to leave it to the system default which is 30 mins. The timeout 
> has been removed from NetscalerResource in order to support login for 
> Netscaler 10.5 devices.
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
>  54e5d50 
> 
> Diff: https://reviews.apache.org/r/22927/diff/
> 
> 
> Testing
> ---
> 
> Timeout was removed and login to the Netscaler devices with the default 
> timeout of 30 minutes was successful. It was tested for Netscaler builds 10.1 
> and 10.5.
> 
> 
> Thanks,
> 
> Sujaya Maiyya
> 
>

Re: Review Request 22927: Bugfix CLOUDSTACK-6261: remove the forceful timeout setting when login to NetScaler.

[Rajesh Battala]

> On June 30, 2014, 11:35 a.m., Rajesh Battala wrote:
> > plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java,
> >  line 2774
> > 
> >
> > Remove the timeout from this method also
> > This fix should have thrown compilation error as the variable not found.
> > 
> > After fixing it Please build the code and post it for review.
> >

This timeout value is dfferent.
Patch looks fine. 
I will apply and push it.


- Rajesh


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


On June 24, 2014, 10:23 a.m., Sujaya Maiyya wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22927/
> ---
> 
> (Updated June 24, 2014, 10:23 a.m.)
> 
> 
> Review request for cloudstack, Murali Reddy and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6261
> https://issues.apache.org/jira/browse/CLOUDSTACK-6261
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The NetScaler Resource forces a idle timeout of 100,000 seconds during login. 
> It is best to leave it to the system default which is 30 mins. The timeout 
> has been removed from NetscalerResource in order to support login for 
> Netscaler 10.5 devices.
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
>  54e5d50 
> 
> Diff: https://reviews.apache.org/r/22927/diff/
> 
> 
> Testing
> ---
> 
> Timeout was removed and login to the Netscaler devices with the default 
> timeout of 30 minutes was successful. It was tested for Netscaler builds 10.1 
> and 10.5.
> 
> 
> Thanks,
> 
> Sujaya Maiyya
> 
>

Re: Review Request 22927: Bugfix CLOUDSTACK-6261: remove the forceful timeout setting when login to NetScaler.

[Rajesh Battala]

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


Unable to apply the patch on latest master. 
can you rebase it to latest master and post it for review.




Applying: Forced timeout is not required. The default timeout value of 30 
minutes will suffice. Removed timeout in order to support login for Netscaler 
10.5 devices.
/home/rajesh/hyperv/.git/rebase-apply/patch:23: trailing whitespace.
_netscalerService.set_credential(_username, _password);
error: patch failed: 
plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java:293
error: 
plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java:
 patch does not apply
Patch failed at 0001 Forced timeout is not required. The default timeout value 
of 30 minutes will suffice. Removed timeout in order to support login for 
Netscaler 10.5 devices.


- Rajesh Battala


On June 24, 2014, 10:23 a.m., Sujaya Maiyya wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22927/
> ---
> 
> (Updated June 24, 2014, 10:23 a.m.)
> 
> 
> Review request for cloudstack, Murali Reddy and Rajesh Battala.
> 
> 
> Bugs: CLOUDSTACK-6261
> https://issues.apache.org/jira/browse/CLOUDSTACK-6261
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The NetScaler Resource forces a idle timeout of 100,000 seconds during login. 
> It is best to leave it to the system default which is 30 mins. The timeout 
> has been removed from NetscalerResource in order to support login for 
> Netscaler 10.5 devices.
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
>  54e5d50 
> 
> Diff: https://reviews.apache.org/r/22927/diff/
> 
> 
> Testing
> ---
> 
> Timeout was removed and login to the Netscaler devices with the default 
> timeout of 30 minutes was successful. It was tested for Netscaler builds 10.1 
> and 10.5.
> 
> 
> Thanks,
> 
> Sujaya Maiyya
> 
>

Re: [ACS4.5] Can't access volumes on storage tab in GUI

[Bharat Kumar]

Hi Mike,

I think the volume_view did not get created properly for some reason. I think 
recreating the volume_view will fix the problem.

below commas should fix the issue.

DROP VIEW IF EXISTS `cloud`.`volume_view`;
CREATE VIEW `cloud`.`volume_view` AS
select
volumes.id,
volumes.uuid,
volumes.name,
volumes.device_id,
volumes.volume_type,
volumes.size,
volumes.min_iops,
volumes.max_iops,
volumes.created,
volumes.state,
volumes.attached,
volumes.removed,
volumes.pod_id,
volumes.display_volume,
volumes.format,
volumes.path,
volumes.chain_info,
account.id account_id,
account.uuid account_uuid,
account.account_name account_name,
account.type account_type,
domain.id domain_id,
domain.uuid domain_uuid,
domain.name domain_name,
domain.path domain_path,
projects.id project_id,
projects.uuid project_uuid,
projects.name project_name,
data_center.id data_center_id,
data_center.uuid data_center_uuid,
data_center.name data_center_name,
data_center.networktype data_center_type,
vm_instance.id vm_id,
vm_instance.uuid vm_uuid,
vm_instance.name vm_name,
vm_instance.state vm_state,
vm_instance.vm_type,
user_vm.display_name vm_display_name,
volume_store_ref.size volume_store_size,
volume_store_ref.download_pct,
volume_store_ref.download_state,
volume_store_ref.error_str,
volume_store_ref.created created_on_store,
disk_offering.id disk_offering_id,
disk_offering.uuid disk_offering_uuid,
disk_offering.name disk_offering_name,
disk_offering.display_text disk_offering_display_text,
disk_offering.use_local_storage,
disk_offering.system_use,
disk_offering.bytes_read_rate,
disk_offering.bytes_write_rate,
disk_offering.iops_read_rate,
disk_offering.iops_write_rate,
disk_offering.cache_mode,
storage_pool.id pool_id,
storage_pool.uuid pool_uuid,
storage_pool.name pool_name,
cluster.hypervisor_type,
vm_template.id template_id,
vm_template.uuid template_uuid,
vm_template.extractable,
vm_template.type template_type,
vm_template.name template_name,
vm_template.display_text template_display_text,
iso.id iso_id,
iso.uuid iso_uuid,
iso.name iso_name,
iso.display_text iso_display_text,
resource_tags.id tag_id,
resource_tags.uuid tag_uuid,
resource_tags.key tag_key,
resource_tags.value tag_value,
resource_tags.domain_id tag_domain_id,
resource_tags.account_id tag_account_id,
resource_tags.resource_id tag_resource_id,
resource_tags.resource_uuid tag_resource_uuid,
resource_tags.resource_type tag_resource_type,
resource_tags.customer tag_customer,
async_job.id job_id,
async_job.uuid job_uuid,
async_job.job_status job_status,
async_job.account_id job_account_id
from
`cloud`.`volumes`
inner join
`cloud`.`account` ON volumes.account_id = account.id
inner join
`cloud`.`domain` ON volumes.domain_id = domain.id
left join
`cloud`.`projects` ON projects.project_account_id = account.id
left join
`cloud`.`data_center` ON volumes.data_center_id = data_center.id
left join
`cloud`.`vm_instance` ON volumes.instance_id = vm_instance.id
left join
`cloud`.`user_vm` ON user_vm.id = vm_instance.id
left join
`cloud`.`volume_store_ref` ON volumes.id = volume_store_ref.volume_id
left join
`cloud`.`disk_offering` ON volumes.disk_offering_id = disk_offering.id
left join
`cloud`.`storage_pool` ON volumes.pool_id = storage_pool.id
left join
`cloud`.`cluster` ON storage_pool.cluster_id = cluster.id
left join
`cloud`.`vm_template` ON volumes.template_id = vm_template.id
left join
`cloud`.`vm_template` iso ON iso.id = volumes.iso_id
left join
`cloud`.`resource_tags` ON resource_tags.resource_id = volumes.id
and resource_tags.resource_type = 'Volume'
left join
`cloud`.`async_job` ON async_job.instance_id = volumes.id
and async_job.instance_type = 'Volume'
and async_job.job_status = 0;

Thanks,
Bharat.

On 28-Jun-2014, at 3:30 am, Mike Tutkowski  wrote:

> Hi,
> 
> If you click on the Storage tab in the GUI when you have one or more
> volumes, you receive the following exception (is this something someone is
> already working on?):
> 
> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException:

Re: [ACS4.4] RC1

[Daan Hoogland]

Ove, to be sure I got you: Does your script need to have the branch
checked out when building a version by tag or commit-id or does it
checkout the version and then build it?

The commit id is not on the branch 4.4 but on a branch of that called
4.4-RCT

But I noticed that you are right, the pom for checkstyle is not edited
in the release.

On Mon, Jun 30, 2014 at 1:29 PM, Ove Ewerlid  wrote:
> On 06/30/2014 11:23 AM, Daan Hoogland wrote:
>>
>> This is going to be the vote thread but I read back the procedure and
>> found that I should more explicitly ask for consent before starting
>> the vote.
>>
>> 162ea957e6f02e56f2de7a639f4c7e593b1b3e72 is the commit id for the
>> version I would like to release. Do we have the feeling that this is a
>> version stable enough?
>>
>> More specific: Citrix QA, do you have a good confidence level with the
>> present state of the 4.4 branch?
>>
>> kind regards,
>>
>
> My build script experience an issue when building versus the 4.4 RC1 commit
> id. The script works with "git checkout 4.4" but when doing "git checkout
> " below issue occurs. The only difference (right now) is
> changing "4.4-SNAPSHOT" --> "4.4.0" throughout the tree.
>
> This Warning is issued;
> [INFO] Building Apache CloudStack Maven Conventions Parent 4.4.0
> [INFO]
> 
> [INFO]
> [INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @
> cloud-maven-standard ---
> [WARNING] The POM for org.apache.cloudstack:checkstyle:jar:4.4.0 is missing,
> no dependency information available
>
> Then build errors out with;
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check
> (cloudstack-checkstyle) on project cloud-maven-standard: Execution
> cloudstack-checkstyle of goal
> org.apache.maven.plugins:maven-checkstyle-plugin\
> :2.11:check failed: Plugin
> org.apache.maven.plugins:maven-checkstyle-plugin:2.11 or one of its
> dependencies could not be resolved: Failure to find
> org.apache.cloudstack:checkstyle:jar:4.4.0 in
> http://repo.maven.apache.org/maven2 was cac\
> hed in the local repository, resolution will not be reattempted until the
> update interval of central has elapsed or updates are forced -> [Help 1]
>
> A usual suspect is the Maven M2 cache, the same error happens when building
> from clean cache and when building on top of a successful 4.4 build that
> populates a cache sufficient for 4.4. Some 10 attempts tried, the same issue
> each time. This is with Maven v3.2.1. Build host is OEL65 with latest
> updates (e.g., effectively RHEL65).
>
> The build script handles 4.3, 4.3.0 and 4.4 without issues, just tested
> that.
>
> Thoughts?
>
> /Ove
>
>
> --
> Ove Everlid
> System Administrator / Architect / SDN- & Automation- & Linux-hacker
> Mobile: +46706668199 (dedicated work mobile)
> Country: Sweden, timezone; Middle Europan Time (MET or GMT+1)



-- 
Daan

Re: [ACS43] upgrade for vlan uris

[sebgoa]

On Jun 30, 2014, at 12:09 PM, Daan Hoogland  wrote:

> Sebastien,
> 
> I just made a port of the vlan uri data migration to the 4.3 branch
> and java 6, in a 430to431 class and am about to commit/push. Do you
> plan to have a quality check on this? I do not have the problem myself
> so maybe someone that did/has should test it.
> 

Just push it, and I will test it.

> -- 
> Daan

Re: Review Request 23150: CLOUDSTACK-7006: Restore template ID in ROOT volume usages

[ASF Subversion and Git Services]

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


Commit caa102c23d352d8e9f2f8a4f4159a3fc7d776f26 in cloudstack's branch 
refs/heads/4.3 from Olivier Lemasle
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=caa102c ]

CLOUDSTACK-7006: Restore template ID in ROOT volume usages

Signed-off-by: Sebastien Goasguen 


- ASF Subversion and Git Services


On June 30, 2014, 8:53 a.m., Olivier Lemasle wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23150/
> ---
> 
> (Updated June 30, 2014, 8:53 a.m.)
> 
> 
> Review request for cloudstack, Kishan Kavala and Sebastien Goasguen.
> 
> 
> Bugs: CLOUDSTACK-7006
> https://issues.apache.org/jira/browse/CLOUDSTACK-7006
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This patch restore the template ID in usages, for ROOT volume created from a 
> template (see CLOUDSTACK-7006).
> 
> The regression was on the class com.cloud.storage.VolumeManagerImpl (module 
> "cloud-server") but it has been renamed 
> org.apache.cloudstack.engine.orchestration.VolumeOrchestrator (module 
> "cloud-engine-orchestration").
> 
> The patch applies on branchs master and branch 4.4.
> I've attached another patch for branch 4.3 (the only difference is 
> formatting).
> 
> 
> Diffs
> -
> 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  9ba3451 
> 
> Diff: https://reviews.apache.org/r/23150/diff/
> 
> 
> Testing
> ---
> 
> Tested in ACS 4.3.
> 1. Deploy a new VM from a template.
> 2. Check if usages for the ROOT volume has the right templateId.
> 3. Deploy a new VM from an ISO, and add a DATA volume.
> 4. Check that there is no regression for these two types of volume usages 
> without templateId.
> 
> 
> File Attachments
> 
> 
> patch version for ACS 4.3
>   
> https://reviews.apache.org/media/uploaded/files/2014/06/29/eee8a901-4141-46e7-b4ce-d9cbcfd8c85f__cloudstack-7006-for-ACS4.3.patch
> 
> 
> Thanks,
> 
> Olivier Lemasle
> 
>

Re: Review Request 23150: CLOUDSTACK-7006: Restore template ID in ROOT volume usages

[Sebastien Goasguen]

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


I applied it to 4.3, I will give Kishan a bit of time to see it and apply to 
master and 4.4 (probably 4.4.1 since we are cutting the RC now).

- Sebastien Goasguen


On June 30, 2014, 8:53 a.m., Olivier Lemasle wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23150/
> ---
> 
> (Updated June 30, 2014, 8:53 a.m.)
> 
> 
> Review request for cloudstack, Kishan Kavala and Sebastien Goasguen.
> 
> 
> Bugs: CLOUDSTACK-7006
> https://issues.apache.org/jira/browse/CLOUDSTACK-7006
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This patch restore the template ID in usages, for ROOT volume created from a 
> template (see CLOUDSTACK-7006).
> 
> The regression was on the class com.cloud.storage.VolumeManagerImpl (module 
> "cloud-server") but it has been renamed 
> org.apache.cloudstack.engine.orchestration.VolumeOrchestrator (module 
> "cloud-engine-orchestration").
> 
> The patch applies on branchs master and branch 4.4.
> I've attached another patch for branch 4.3 (the only difference is 
> formatting).
> 
> 
> Diffs
> -
> 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  9ba3451 
> 
> Diff: https://reviews.apache.org/r/23150/diff/
> 
> 
> Testing
> ---
> 
> Tested in ACS 4.3.
> 1. Deploy a new VM from a template.
> 2. Check if usages for the ROOT volume has the right templateId.
> 3. Deploy a new VM from an ISO, and add a DATA volume.
> 4. Check that there is no regression for these two types of volume usages 
> without templateId.
> 
> 
> File Attachments
> 
> 
> patch version for ACS 4.3
>   
> https://reviews.apache.org/media/uploaded/files/2014/06/29/eee8a901-4141-46e7-b4ce-d9cbcfd8c85f__cloudstack-7006-for-ACS4.3.patch
> 
> 
> Thanks,
> 
> Olivier Lemasle
> 
>

Re: [ACS4.4] RC1

[Ove Ewerlid]

On 06/30/2014 02:51 PM, Daan Hoogland wrote:

Ove, to be sure I got you: Does your script need to have the branch
checked out when building a version by tag or commit-id or does it
checkout the version and then build it?


The script is setup for the historical ACS method of using a specific 
commit ID to denote a release that later is turned into a tag as the 
vote is passed, all using the 4.0, 4.1, 4.2, 4.3, base branch.


That being said, I noticed that the first commit ID you gave for 4.4 RC1 
was not part of the 4.4 tree. Hence, changed the build script to also 
support checking out a specific "release" branch. A later 44RC1 commit 
id was part of 4.4 branch.


Probably time to enhance ACS build script to use "git remote show 
origin" and sieve out the branches related to a release/vote process in 
time order and work on the last one.



The commit id is not on the branch 4.4 but on a branch of that called
4.4-RCT

But I noticed that you are right, the pom for checkstyle is not edited
in the release.


ok

/Ove



On Mon, Jun 30, 2014 at 1:29 PM, Ove Ewerlid  wrote:

On 06/30/2014 11:23 AM, Daan Hoogland wrote:


This is going to be the vote thread but I read back the procedure and
found that I should more explicitly ask for consent before starting
the vote.

162ea957e6f02e56f2de7a639f4c7e593b1b3e72 is the commit id for the
version I would like to release. Do we have the feeling that this is a
version stable enough?

More specific: Citrix QA, do you have a good confidence level with the
present state of the 4.4 branch?

kind regards,



My build script experience an issue when building versus the 4.4 RC1 commit
id. The script works with "git checkout 4.4" but when doing "git checkout
" below issue occurs. The only difference (right now) is
changing "4.4-SNAPSHOT" --> "4.4.0" throughout the tree.

This Warning is issued;
[INFO] Building Apache CloudStack Maven Conventions Parent 4.4.0
[INFO]

[INFO]
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @
cloud-maven-standard ---
[WARNING] The POM for org.apache.cloudstack:checkstyle:jar:4.4.0 is missing,
no dependency information available

Then build errors out with;

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check
(cloudstack-checkstyle) on project cloud-maven-standard: Execution
cloudstack-checkstyle of goal
org.apache.maven.plugins:maven-checkstyle-plugin\
:2.11:check failed: Plugin
org.apache.maven.plugins:maven-checkstyle-plugin:2.11 or one of its
dependencies could not be resolved: Failure to find
org.apache.cloudstack:checkstyle:jar:4.4.0 in
http://repo.maven.apache.org/maven2 was cac\
hed in the local repository, resolution will not be reattempted until the
update interval of central has elapsed or updates are forced -> [Help 1]

A usual suspect is the Maven M2 cache, the same error happens when building
from clean cache and when building on top of a successful 4.4 build that
populates a cache sufficient for 4.4. Some 10 attempts tried, the same issue
each time. This is with Maven v3.2.1. Build host is OEL65 with latest
updates (e.g., effectively RHEL65).

The build script handles 4.3, 4.3.0 and 4.4 without issues, just tested
that.

Thoughts?

/Ove


--
Ove Everlid
System Administrator / Architect / SDN- & Automation- & Linux-hacker
Mobile: +46706668199 (dedicated work mobile)
Country: Sweden, timezone; Middle Europan Time (MET or GMT+1)







--
Ove Everlid
System Administrator / Architect / SDN- & Automation- & Linux-hacker
Mobile: +46706668199 (dedicated work mobile)
Country: Sweden, timezone; Middle Europan Time (MET or GMT+1)

Re: [ACS43] upgrade for vlan uris

[Daan Hoogland]

pushed

On Mon, Jun 30, 2014 at 3:00 PM, sebgoa  wrote:
>
> On Jun 30, 2014, at 12:09 PM, Daan Hoogland  wrote:
>
>> Sebastien,
>>
>> I just made a port of the vlan uri data migration to the 4.3 branch
>> and java 6, in a 430to431 class and am about to commit/push. Do you
>> plan to have a quality check on this? I do not have the problem myself
>> so maybe someone that did/has should test it.
>>
>
> Just push it, and I will test it.
>
>> --
>> Daan
>



-- 
Daan

Re: [ACS431][QUESTION] db upgrace

[sebgoa]

On Jun 18, 2014, at 6:19 AM, Koushik Das  wrote:

> 4.3.1 -> 4.4.0 upgrade also needs to be handled.
> 

Daan pushed a 4.3.0 to 4.3.1 in the 4.3 branch just now.

the 4.3.1 to 4.4.0 needs to be in the 4.4 branch (maybe even the RC of 4.4.0) 
or it will go in 4.4.1 

yes ?

> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] 
> Sent: Tuesday, 17 June 2014 9:16 PM
> To: dev
> Subject: [ACS431][QUESTION] db upgrace
> 
> In my simple mind it seems we only need to create a Upgrade430to431.java file 
> and don't need any sql files. Is this going to fly? AFAICT the only thing to 
> go in there is the vlan fixup in the vlan table, which is a data migration 
> and not a schema change.
> 
> Can anyone point out to me the error in my ways, please?
> 
> thanks,
> --
> Daan

[v.mel...@uplink.ua: MonkeyMan - a perl5 library for managing your Apache CloudStack installation]

[Vladimir Melnik]

Just for your info.

- Forwarded message from Vladimir Melnik  -

Date: Mon, 30 Jun 2014 15:24:55 +0300
From: Vladimir Melnik 
To: us...@cloudstack.apache.org
Subject: MonkeyMan - a perl5 library for managing your Apache CloudStack 
installation
User-Agent: Mutt/1.5.20 (2009-12-10)

Dear colleagues,

If you administrating CloudStack installations, you may find it useful.
If you love Perl5, you may consider it interesting.

I'm developing a library and some set of tools for managing
CloudStack-based infrastructure from the command line. It's going to
become a smart system for doing lots of administrative tasks, so it's
only the beginning for now. :-)

But what we have at the moment?

As about tools, we can do such things from UNIX-shell...

For example, let's assume you want to check state of the VM having
a certain IP-address AND being a member of a certain domain:

admin> mm_vm_info has_ipaddress=10.1.1.127 has_domain=A201306



  
99b885d4-70d7-4efc-8a4e-53417893fb19
99b885d4-70d7-4efc-8a4e-53417893fb19
[...]

Or, if you want to, you can get certain parameters of this output:

admin> mm_vm_info has_ipaddress=10.1.1.127 has_domain=A201306 \
-x //state -x //hostname -x //instancename

Running
h2.c1.p1.z1.tucha13.net
i-51-135-VM

You can reset the VM found by your desired criterias:

admin> mm_vm_reset has_instancename=i-13-666-VM

Want to listen to someone's network interface? No problem.

admin> mm_vm_tcpdump has_ipaddress=10.1.1.253
tcpdump: WARNING: vnet17: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vnet17, link-type EN10MB (Ethernet), capture size 65535 bytes
15:21:01.845886 IP 10.1.1.1.36686 > 10.1.1.253.imaps: Flags [S], seq 316746440, 
win 14600, options [mss 1460,sackOK,TS val 1959872931 ecr 0,nop,wscale 6], 
length 0
15:21:01.846023 IP 10.1.1.253.imaps > 10.1.1.1.36686: Flags [S.], seq 
2234071684, ack 316746441, win 14480, options [mss 1460,sackOK,TS val 
2579908884 ecr 1959872931,nop,wscale 6], length 0

^^^ The script have found the hostname and the instance name, logged
into the host, analyzed output of "virsh dumpxml ...", found the
interface's name (vnet17) and launched tcpdump.

And you can use all these things not only from the command-line, as you
can use the object oriented library using all these things from your own
Perl5 scripts.

Let's assume you want to find and load all the information about some
domain:

my $domain = eval { MonkeyMan::CloudStack::Elements::Domain->new(
mm  => $mm,
load_dom=> {
conditions  => {
path=> 'ROOT/CUSTOMERS/ZALOOPA'
}
}
)};

if($@) { $log->warn("Can't 
MonkeyMan::CloudStack::Elements::Domain->new(): $@"); next; }

Voila, now you have the corresponding object's reference in the $domain
variable. You can do some easy tricks with that domain. It's pretty easy
to get any parameter:

my $domain_id = $domain->get_parameter('id');

unless(defined($domain_id)) {
$log->warn("Can't get the ID of the domain" .
($domain->has_error ? (": " . $domain->error_message) : 
undef)
);
next;
}

What if you want to get all volumes belongs to this domain? It's easy:

my $volumz = $domain->find_related_to_me("volume");
$log->logdie($domain->error_message) unless defined($volumz);

No kidding, you have the reference to the list of XML::LibXML documents
who have the  parameter corresponding to this domain. You can
easily initialize them as objects to do other cool things with these
volumes:

foreach my $volume_dom (@{ $volumz }) {

my $volume = eval { 
MonkeyMan::CloudStack::Elements::Volume->new(
mm  => $mm,
load_dom=> {
 dom=> $volume_dom   # the XML document
}
); };
if($@) { $log->warn("Can't 
MonkeyMan::CloudStack::Elements::Volume->new(): $@"); next; }

Oh, well, too much words... :-)

Would you like to use it? You're strongly welcome:

https://github.com/melnik13/monkeyman/

Would you like to develop it with me? Feel free to drop me a line.

A great week to you all!


-- 
V.Melnik

- End forwarded message -

-- 
V.Melnik

Review Request 23169: CLOUDSTACK-7010: Add domain to createZones in marvin

[John Dilley]

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

Review request for cloudstack and Santhosh Edukulla.


Repository: cloudstack-git


Description
---

Add domain to createZones in deployDataCenter


Diffs
-

  tools/marvin/marvin/configGenerator.py 8d9 
  tools/marvin/marvin/deployDataCenter.py c097238 

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


Testing
---

Tested deployDataCenter, both with and without specifying a domain


Thanks,

John Dilley

Review Request 23168: Update cloudstack-usage JAVA_HOME to find JRE for Java 7

[Olivier Lemasle]

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

Review request for cloudstack and Sebastien Goasguen.


Repository: cloudstack-git


Description
---

cloudstack-usage is currently configured to search JAVA_HOME only in a small 
set of paths corresponding to Java 6 (/usr/lib/jvm/java-6-openjdk, 
/usr/lib/jvm/java-6-openjdk-i386, etc).

If cloudstack-usage is installed on a server with only Java 7, the service 
cannot start and fails with the following error:
jsvc error: Cannot locate Java Home

This commit adds Java 7 paths to the possible set of JAVA_HOME locations.


Diffs
-

  usage/distro/centos/SYSCONFDIR/rc.d/init.d/cloud-usage.in cb5beb5 
  usage/distro/fedora/SYSCONFDIR/rc.d/init.d/cloud-usage.in cb5beb5 
  usage/distro/opensuse/SYSCONFDIR/init.d/cloud-usage.in f968263 
  usage/distro/rhel/SYSCONFDIR/rc.d/init.d/cloud-usage.in cb5beb5 
  usage/distro/sles/SYSCONFDIR/init.d/cloud-usage.in f968263 
  usage/distro/ubuntu/SYSCONFDIR/init.d/cloud-usage.in f968263 

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


Testing
---


Thanks,

Olivier Lemasle

Re: [ACS431][QUESTION] db upgrace

[Daan Hoogland]

at the moment there is no special case for 4.3.1 to 4.4 (.0 or .1)

On Mon, Jun 30, 2014 at 3:22 PM, sebgoa  wrote:
>
> On Jun 18, 2014, at 6:19 AM, Koushik Das  wrote:
>
>> 4.3.1 -> 4.4.0 upgrade also needs to be handled.
>>
>
> Daan pushed a 4.3.0 to 4.3.1 in the 4.3 branch just now.
>
> the 4.3.1 to 4.4.0 needs to be in the 4.4 branch (maybe even the RC of 4.4.0) 
> or it will go in 4.4.1
>
> yes ?
>
>> -Original Message-
>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> Sent: Tuesday, 17 June 2014 9:16 PM
>> To: dev
>> Subject: [ACS431][QUESTION] db upgrace
>>
>> In my simple mind it seems we only need to create a Upgrade430to431.java 
>> file and don't need any sql files. Is this going to fly? AFAICT the only 
>> thing to go in there is the vlan fixup in the vlan table, which is a data 
>> migration and not a schema change.
>>
>> Can anyone point out to me the error in my ways, please?
>>
>> thanks,
>> --
>> Daan
>



-- 
Daan

Re: CLOUDSTACK-7005 - Failed to start MS with latest 4.4 RPM builds

[Mike Tutkowski]

Hi Daan,

That essentially answers my question - thanks. It sounds like you are
saying that we did not add a new feature, but rather we fixed an existing
security issue. If that's the case, sounds good.

In general I would say at this point in the release that we need to be
asking the following question: "Would we hold the release if this
particular bug is not fixed?" If yes, then we should check in such a fix;
else, we shouldn't.

I would add that we should have exemptions for trivial issues like text
fixes. For example, a typo that someone found and fixed should be allowed
in because it adds to the overall professionalism of the software and
introduces minimal risk.

What do you think?

Thanks,
Mike


On Mon, Jun 30, 2014 at 12:31 AM, Daan Hoogland 
wrote:

> Mike, I have been scanning all commits since code freeze but I can't
> say I am a fool proof filter. In General I don't agree that issues
> must have been blockers for related code to be allowed in. They must
> have been issues with the existing code and not with new features,
> though. A trivial error may block us. I would like to see issues
> discussed more so we can decide whether and what are blockers. An
> issue being 'marked as blocker' is less interesting to me.
>
> Your worry is not vain when you mean: Did we allow for more code being
> added then necessary?
> I decided in this case on yes because of the issue it was solving. The
> issue the code was related to had to do with an security.
>
> Daan
>
> On Mon, Jun 30, 2014 at 3:28 AM, Mike Tutkowski
>  wrote:
> > Just curious...if we are breaking basic functionality right before our
> > first 4.4 RC, did this happen with code that was related to a Blocker
> > defect? If not, it makes me wonder if the code in question should perhaps
> > have waited until a maintenance release for 4.4...or 4.5 if no such
> > maintenance release occurs.
> >
> > If it's related to new functionality, I'd be a bit surprised as we're way
> > past that point for 4.4.
> >
> >
> > On Sun, Jun 29, 2014 at 2:02 PM, Rayees Namathponnan <
> > rayees.namathpon...@citrix.com> wrote:
> >
> >> Thanks Ian
> >>
> >>
> >>
> >>
> >> On 6/29/14, 10:59 AM, "Ian Duffy"  wrote:
> >>
> >> >Hi Rayees,
> >> >
> >> >Pushed a change on this.
> >> >
> >> >
> >>
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setu
> >>
> >p/db/db/schema-430to440.sql;h=8ab2ffba0a4a23dbb9acb0245793b5916ef0a3f7;hp=
> >>
> >6c9783a9781993a5bb7127083baa2efaad69e8fb;hb=f7417d622a15c9ff6a5d6e5e7284bd
> >> >220bc647ee;hpb=46f2b61374c2012bca251c1de58fb1250e50b755
> >> >
> >> >
> >> >
> >> >
> >> >On 29 June 2014 18:22, Ian Duffy  wrote:
> >> >
> >> >> Hi Rayees,
> >> >>
> >> >> Looking at it right now. Hope to have a fix for you shortly.
> >> >>
> >> >>
> >> >> On 29 June 2014 18:14, Rayees Namathponnan
> >> >> >> >> > wrote:
> >> >>
> >> >>> I reverted below two commits from local build machine, after that I
> >> >>> didn't see the issue reported in 7005
> >> >>>
> >> >>> Ian - can you please look your last check-in ?
> >> >>>
> >> >>> Regards,
> >> >>> Rayees
> >> >>>
> >> >>> -Original Message-
> >> >>> From: Rayees Namathponnan [mailto:rayees.namathpon...@citrix.com]
> >> >>> Sent: Sunday, June 29, 2014 8:50 AM
> >> >>> To: dev@cloudstack.apache.org
> >> >>> Subject: CLOUDSTACK-7005 - Failed to start MS with latest 4.4 RPM
> >> >>>builds
> >> >>>
> >> >>> Hi All,
> >> >>>
> >> >>> Failed to start MS with latest 4.4 RPM builds, getting below error
> >> >>>
> >> >>> 2014-06-29 07:43:12,466 INFO  [c.c.c.ClusterManagerImpl] (main:null)
> >> >>> Cluster node IP : 10.223.49.197
> >> >>> 2014-06-29 07:43:12,479 INFO  [c.c.c.ClusterManagerImpl] (main:null)
> >> >>> Cluster manager is configured.
> >> >>> 2014-06-29 07:43:12,648 DEBUG [c.c.u.c.DBEncryptionUtil] (main:null)
> >> >>> Error while decrypting: 6
> >> >>> 2014-06-29 07:43:29,465 INFO  [c.c.u.c.ComponentContext] (main:null)
> >> >>> Configuring
> >> >>>
> >>
> >>>com.cloud.bridge.persist.dao.CloudStackAccountDaoImpl_EnhancerByCloudSta
> >> >>>ck_f8e983ac
> >> >>>
> >> >>> This might be due to below check-in, but not sure
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=se
> >>
> >>>tup/db/db/schema-430to440.sql;h=6c9783a9781993a5bb7127083baa2efaad69e8fb
> >>
> >>>;hp=0293986167cd663a72d0849ab51073fc5f84da31;hb=96412e3e58fd1ced9d269e45
> >> >>>52aaa6410bedf556;hpb=2498f65683bd529b2b03bac9a6cfd2fdbf65aca2
> >> >>>
> >> >>>
> >> >>> Regards,
> >> >>> Rayees
> >> >>>
> >> >>
> >> >>
> >>
> >>
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > *™*
>
>
>
> --
> Daan
>



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

Re: [ACS4.5] Can't access volumes on storage tab in GUI

[Mike Tutkowski]

Thanks for the reply.

The weird part is that this is the second time I've recreated the DB and
seen this issue.

If I have time a bit later, I can see if the SQL in Git is wrong and update
it with what you provided.

Thanks!


On Mon, Jun 30, 2014 at 5:47 AM, Bharat Kumar 
wrote:

> Hi Mike,
>
> I think the volume_view did not get created properly for some reason. I
> think recreating the volume_view will fix the problem.
>
> below commas should fix the issue.
>
> DROP VIEW IF EXISTS `cloud`.`volume_view`;
> CREATE VIEW `cloud`.`volume_view` AS
> select
> volumes.id,
> volumes.uuid,
> volumes.name,
> volumes.device_id,
> volumes.volume_type,
> volumes.size,
> volumes.min_iops,
> volumes.max_iops,
> volumes.created,
> volumes.state,
> volumes.attached,
> volumes.removed,
> volumes.pod_id,
> volumes.display_volume,
> volumes.format,
> volumes.path,
> volumes.chain_info,
> account.id account_id,
> account.uuid account_uuid,
> account.account_name account_name,
> account.type account_type,
> domain.id domain_id,
> domain.uuid domain_uuid,
> domain.name domain_name,
> domain.path domain_path,
> projects.id project_id,
> projects.uuid project_uuid,
> projects.name project_name,
> data_center.id data_center_id,
> data_center.uuid data_center_uuid,
> data_center.name data_center_name,
> data_center.networktype data_center_type,
> vm_instance.id vm_id,
> vm_instance.uuid vm_uuid,
> vm_instance.name vm_name,
> vm_instance.state vm_state,
> vm_instance.vm_type,
> user_vm.display_name vm_display_name,
> volume_store_ref.size volume_store_size,
> volume_store_ref.download_pct,
> volume_store_ref.download_state,
> volume_store_ref.error_str,
> volume_store_ref.created created_on_store,
> disk_offering.id disk_offering_id,
> disk_offering.uuid disk_offering_uuid,
> disk_offering.name disk_offering_name,
> disk_offering.display_text disk_offering_display_text,
> disk_offering.use_local_storage,
> disk_offering.system_use,
> disk_offering.bytes_read_rate,
> disk_offering.bytes_write_rate,
> disk_offering.iops_read_rate,
> disk_offering.iops_write_rate,
> disk_offering.cache_mode,
> storage_pool.id pool_id,
> storage_pool.uuid pool_uuid,
> storage_pool.name pool_name,
> cluster.hypervisor_type,
> vm_template.id template_id,
> vm_template.uuid template_uuid,
> vm_template.extractable,
> vm_template.type template_type,
> vm_template.name template_name,
> vm_template.display_text template_display_text,
> iso.id iso_id,
> iso.uuid iso_uuid,
> iso.name iso_name,
> iso.display_text iso_display_text,
> resource_tags.id tag_id,
> resource_tags.uuid tag_uuid,
> resource_tags.key tag_key,
> resource_tags.value tag_value,
> resource_tags.domain_id tag_domain_id,
> resource_tags.account_id tag_account_id,
> resource_tags.resource_id tag_resource_id,
> resource_tags.resource_uuid tag_resource_uuid,
> resource_tags.resource_type tag_resource_type,
> resource_tags.customer tag_customer,
> async_job.id job_id,
> async_job.uuid job_uuid,
> async_job.job_status job_status,
> async_job.account_id job_account_id
> from
> `cloud`.`volumes`
> inner join
> `cloud`.`account` ON volumes.account_id = account.id
> inner join
> `cloud`.`domain` ON volumes.domain_id = domain.id
> left join
> `cloud`.`projects` ON projects.project_account_id = account.id
> left join
> `cloud`.`data_center` ON volumes.data_center_id = data_center.id
> left join
> `cloud`.`vm_instance` ON volumes.instance_id = vm_instance.id
> left join
> `cloud`.`user_vm` ON user_vm.id = vm_instance.id
> left join
> `cloud`.`volume_store_ref` ON volumes.id =
> volume_store_ref.volume_id
> left join
> `cloud`.`disk_offering` ON volumes.disk_offering_id =
> disk_offering.id
> left join
> `cloud`.`storage_pool` ON volumes.pool_id = storage_pool.id
> left join
> `cloud`.`cluster` ON storage_pool.cluster_id = cluster.id
> left join
> `cloud`.`vm_template` ON volumes.template_id = vm_template.id
> left join
> `cloud`.`vm_template` iso ON iso.id = volumes.iso_id
> left join
> `cloud`.`resource_tags` ON resource_tags.resource_id = volumes.id
> and resource_tags.resourc

Re: CLOUDSTACK-7005 - Failed to start MS with latest 4.4 RPM builds

[Daan Hoogland]

I have no thoughts that you didn't just express

On Mon, Jun 30, 2014 at 5:03 PM, Mike Tutkowski
 wrote:
> Hi Daan,
>
> That essentially answers my question - thanks. It sounds like you are
> saying that we did not add a new feature, but rather we fixed an existing
> security issue. If that's the case, sounds good.
>
> In general I would say at this point in the release that we need to be
> asking the following question: "Would we hold the release if this
> particular bug is not fixed?" If yes, then we should check in such a fix;
> else, we shouldn't.
>
> I would add that we should have exemptions for trivial issues like text
> fixes. For example, a typo that someone found and fixed should be allowed
> in because it adds to the overall professionalism of the software and
> introduces minimal risk.
>
> What do you think?
>
> Thanks,
> Mike
>
>
> On Mon, Jun 30, 2014 at 12:31 AM, Daan Hoogland 
> wrote:
>
>> Mike, I have been scanning all commits since code freeze but I can't
>> say I am a fool proof filter. In General I don't agree that issues
>> must have been blockers for related code to be allowed in. They must
>> have been issues with the existing code and not with new features,
>> though. A trivial error may block us. I would like to see issues
>> discussed more so we can decide whether and what are blockers. An
>> issue being 'marked as blocker' is less interesting to me.
>>
>> Your worry is not vain when you mean: Did we allow for more code being
>> added then necessary?
>> I decided in this case on yes because of the issue it was solving. The
>> issue the code was related to had to do with an security.
>>
>> Daan
>>
>> On Mon, Jun 30, 2014 at 3:28 AM, Mike Tutkowski
>>  wrote:
>> > Just curious...if we are breaking basic functionality right before our
>> > first 4.4 RC, did this happen with code that was related to a Blocker
>> > defect? If not, it makes me wonder if the code in question should perhaps
>> > have waited until a maintenance release for 4.4...or 4.5 if no such
>> > maintenance release occurs.
>> >
>> > If it's related to new functionality, I'd be a bit surprised as we're way
>> > past that point for 4.4.
>> >
>> >
>> > On Sun, Jun 29, 2014 at 2:02 PM, Rayees Namathponnan <
>> > rayees.namathpon...@citrix.com> wrote:
>> >
>> >> Thanks Ian
>> >>
>> >>
>> >>
>> >>
>> >> On 6/29/14, 10:59 AM, "Ian Duffy"  wrote:
>> >>
>> >> >Hi Rayees,
>> >> >
>> >> >Pushed a change on this.
>> >> >
>> >> >
>> >>
>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=setu
>> >>
>> >p/db/db/schema-430to440.sql;h=8ab2ffba0a4a23dbb9acb0245793b5916ef0a3f7;hp=
>> >>
>> >6c9783a9781993a5bb7127083baa2efaad69e8fb;hb=f7417d622a15c9ff6a5d6e5e7284bd
>> >> >220bc647ee;hpb=46f2b61374c2012bca251c1de58fb1250e50b755
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >On 29 June 2014 18:22, Ian Duffy  wrote:
>> >> >
>> >> >> Hi Rayees,
>> >> >>
>> >> >> Looking at it right now. Hope to have a fix for you shortly.
>> >> >>
>> >> >>
>> >> >> On 29 June 2014 18:14, Rayees Namathponnan
>> >> >>> >> >> > wrote:
>> >> >>
>> >> >>> I reverted below two commits from local build machine, after that I
>> >> >>> didn't see the issue reported in 7005
>> >> >>>
>> >> >>> Ian - can you please look your last check-in ?
>> >> >>>
>> >> >>> Regards,
>> >> >>> Rayees
>> >> >>>
>> >> >>> -Original Message-
>> >> >>> From: Rayees Namathponnan [mailto:rayees.namathpon...@citrix.com]
>> >> >>> Sent: Sunday, June 29, 2014 8:50 AM
>> >> >>> To: dev@cloudstack.apache.org
>> >> >>> Subject: CLOUDSTACK-7005 - Failed to start MS with latest 4.4 RPM
>> >> >>>builds
>> >> >>>
>> >> >>> Hi All,
>> >> >>>
>> >> >>> Failed to start MS with latest 4.4 RPM builds, getting below error
>> >> >>>
>> >> >>> 2014-06-29 07:43:12,466 INFO  [c.c.c.ClusterManagerImpl] (main:null)
>> >> >>> Cluster node IP : 10.223.49.197
>> >> >>> 2014-06-29 07:43:12,479 INFO  [c.c.c.ClusterManagerImpl] (main:null)
>> >> >>> Cluster manager is configured.
>> >> >>> 2014-06-29 07:43:12,648 DEBUG [c.c.u.c.DBEncryptionUtil] (main:null)
>> >> >>> Error while decrypting: 6
>> >> >>> 2014-06-29 07:43:29,465 INFO  [c.c.u.c.ComponentContext] (main:null)
>> >> >>> Configuring
>> >> >>>
>> >>
>> >>>com.cloud.bridge.persist.dao.CloudStackAccountDaoImpl_EnhancerByCloudSta
>> >> >>>ck_f8e983ac
>> >> >>>
>> >> >>> This might be due to below check-in, but not sure
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >>
>> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=se
>> >>
>> >>>tup/db/db/schema-430to440.sql;h=6c9783a9781993a5bb7127083baa2efaad69e8fb
>> >>
>> >>>;hp=0293986167cd663a72d0849ab51073fc5f84da31;hb=96412e3e58fd1ced9d269e45
>> >> >>>52aaa6410bedf556;hpb=2498f65683bd529b2b03bac9a6cfd2fdbf65aca2
>> >> >>>
>> >> >>>
>> >> >>> Regards,
>> >> >>> Rayees
>> >> >>>
>> >> >>
>> >> >>
>> >>
>> >>
>> >
>> >
>> > --
>> > *Mike Tutkowski*
>> > *Senior CloudStack Developer, SolidFire Inc.*
>> > e: mike.tutkow...@solidfire.com
>> > o: 303.746.7302
>> > Advancing the way t

Re: Review Request 23168: Update cloudstack-usage JAVA_HOME to find JRE for Java 7

[Olivier Lemasle]

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

(Updated June 30, 2014, 5:54 p.m.)


Review request for cloudstack and Sebastien Goasguen.


Repository: cloudstack-git


Description
---

cloudstack-usage is currently configured to search JAVA_HOME only in a small 
set of paths corresponding to Java 6 (/usr/lib/jvm/java-6-openjdk, 
/usr/lib/jvm/java-6-openjdk-i386, etc).

If cloudstack-usage is installed on a server with only Java 7, the service 
cannot start and fails with the following error:
jsvc error: Cannot locate Java Home

This commit adds Java 7 paths to the possible set of JAVA_HOME locations.


Diffs (updated)
-

  packaging/centos63/cloud-usage.rc e78f8c1 

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


Testing (updated)
---

Package CloudStack RPMs for CentOS and install them on a system with 
java-1.7.0-openjdk and no Java 6 JRE.
Check that cloudstack-usage works correctly.


Thanks,

Olivier Lemasle

Re: [ACS431][QUESTION] db upgrace

[David Nalley]

Well, if the DB reports it's version 4.3.1, it will have no upgrade
path to 4.4.0 and will fail. Unless something has changed very
recently.

--David

On Mon, Jun 30, 2014 at 10:49 AM, Daan Hoogland  wrote:
> at the moment there is no special case for 4.3.1 to 4.4 (.0 or .1)
>
> On Mon, Jun 30, 2014 at 3:22 PM, sebgoa  wrote:
>>
>> On Jun 18, 2014, at 6:19 AM, Koushik Das  wrote:
>>
>>> 4.3.1 -> 4.4.0 upgrade also needs to be handled.
>>>
>>
>> Daan pushed a 4.3.0 to 4.3.1 in the 4.3 branch just now.
>>
>> the 4.3.1 to 4.4.0 needs to be in the 4.4 branch (maybe even the RC of 
>> 4.4.0) or it will go in 4.4.1
>>
>> yes ?
>>
>>> -Original Message-
>>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>>> Sent: Tuesday, 17 June 2014 9:16 PM
>>> To: dev
>>> Subject: [ACS431][QUESTION] db upgrace
>>>
>>> In my simple mind it seems we only need to create a Upgrade430to431.java 
>>> file and don't need any sql files. Is this going to fly? AFAICT the only 
>>> thing to go in there is the vlan fixup in the vlan table, which is a data 
>>> migration and not a schema change.
>>>
>>> Can anyone point out to me the error in my ways, please?
>>>
>>> thanks,
>>> --
>>> Daan
>>
>
>
>
> --
> Daan

Re: [ACS4.4] RC1

[Daan Hoogland]

499ff73f1a14bddd81c5788930c43b2a3de099ed is the one that has the
checkstyle pom edited as well. It is on branch 4.4-RC20140630T1754.
This time I ran mvn clean test *after* running build_asf.sh threw it
away and ran the script again. Hopefully it will be alright now.
Please proof me wrong, I dare you all.

Daan

On Mon, Jun 30, 2014 at 3:11 PM, Ove Ewerlid  wrote:
> On 06/30/2014 02:51 PM, Daan Hoogland wrote:
>>
>> Ove, to be sure I got you: Does your script need to have the branch
>> checked out when building a version by tag or commit-id or does it
>> checkout the version and then build it?
>
>
> The script is setup for the historical ACS method of using a specific commit
> ID to denote a release that later is turned into a tag as the vote is
> passed, all using the 4.0, 4.1, 4.2, 4.3, base branch.
>
> That being said, I noticed that the first commit ID you gave for 4.4 RC1 was
> not part of the 4.4 tree. Hence, changed the build script to also support
> checking out a specific "release" branch. A later 44RC1 commit id was part
> of 4.4 branch.
>
> Probably time to enhance ACS build script to use "git remote show origin"
> and sieve out the branches related to a release/vote process in time order
> and work on the last one.
>
>
>> The commit id is not on the branch 4.4 but on a branch of that called
>> 4.4-RCT
>>
>> But I noticed that you are right, the pom for checkstyle is not edited
>> in the release.
>
>
> ok
>
> /Ove
>
>
>
>> On Mon, Jun 30, 2014 at 1:29 PM, Ove Ewerlid 
>> wrote:
>>>
>>> On 06/30/2014 11:23 AM, Daan Hoogland wrote:


 This is going to be the vote thread but I read back the procedure and
 found that I should more explicitly ask for consent before starting
 the vote.

 162ea957e6f02e56f2de7a639f4c7e593b1b3e72 is the commit id for the
 version I would like to release. Do we have the feeling that this is a
 version stable enough?

 More specific: Citrix QA, do you have a good confidence level with the
 present state of the 4.4 branch?

 kind regards,

>>>
>>> My build script experience an issue when building versus the 4.4 RC1
>>> commit
>>> id. The script works with "git checkout 4.4" but when doing "git checkout
>>> " below issue occurs. The only difference (right now) is
>>> changing "4.4-SNAPSHOT" --> "4.4.0" throughout the tree.
>>>
>>> This Warning is issued;
>>> [INFO] Building Apache CloudStack Maven Conventions Parent 4.4.0
>>> [INFO]
>>> 
>>> [INFO]
>>> [INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @
>>> cloud-maven-standard ---
>>> [WARNING] The POM for org.apache.cloudstack:checkstyle:jar:4.4.0 is
>>> missing,
>>> no dependency information available
>>>
>>> Then build errors out with;
>>>
>>> [ERROR] Failed to execute goal
>>> org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check
>>> (cloudstack-checkstyle) on project cloud-maven-standard: Execution
>>> cloudstack-checkstyle of goal
>>> org.apache.maven.plugins:maven-checkstyle-plugin\
>>> :2.11:check failed: Plugin
>>> org.apache.maven.plugins:maven-checkstyle-plugin:2.11 or one of its
>>> dependencies could not be resolved: Failure to find
>>> org.apache.cloudstack:checkstyle:jar:4.4.0 in
>>> http://repo.maven.apache.org/maven2 was cac\
>>> hed in the local repository, resolution will not be reattempted until the
>>> update interval of central has elapsed or updates are forced -> [Help 1]
>>>
>>> A usual suspect is the Maven M2 cache, the same error happens when
>>> building
>>> from clean cache and when building on top of a successful 4.4 build that
>>> populates a cache sufficient for 4.4. Some 10 attempts tried, the same
>>> issue
>>> each time. This is with Maven v3.2.1. Build host is OEL65 with latest
>>> updates (e.g., effectively RHEL65).
>>>
>>> The build script handles 4.3, 4.3.0 and 4.4 without issues, just tested
>>> that.
>>>
>>> Thoughts?
>>>
>>> /Ove
>>>
>>>
>>> --
>>> Ove Everlid
>>> System Administrator / Architect / SDN- & Automation- & Linux-hacker
>>> Mobile: +46706668199 (dedicated work mobile)
>>> Country: Sweden, timezone; Middle Europan Time (MET or GMT+1)
>>
>>
>>
>>
>
>
> --
> Ove Everlid
> System Administrator / Architect / SDN- & Automation- & Linux-hacker
> Mobile: +46706668199 (dedicated work mobile)
> Country: Sweden, timezone; Middle Europan Time (MET or GMT+1)



-- 
Daan

Re: [ACS431][QUESTION] db upgrace

[Daan Hoogland]

ok, so we will have to add an upgrade 431to440 which is identical to
430to440. This would be only an entry in the map, no extra classes
needed, i would imagine.

On Mon, Jun 30, 2014 at 6:02 PM, David Nalley  wrote:
> Well, if the DB reports it's version 4.3.1, it will have no upgrade
> path to 4.4.0 and will fail. Unless something has changed very
> recently.
>
> --David
>
> On Mon, Jun 30, 2014 at 10:49 AM, Daan Hoogland  
> wrote:
>> at the moment there is no special case for 4.3.1 to 4.4 (.0 or .1)
>>
>> On Mon, Jun 30, 2014 at 3:22 PM, sebgoa  wrote:
>>>
>>> On Jun 18, 2014, at 6:19 AM, Koushik Das  wrote:
>>>
 4.3.1 -> 4.4.0 upgrade also needs to be handled.

>>>
>>> Daan pushed a 4.3.0 to 4.3.1 in the 4.3 branch just now.
>>>
>>> the 4.3.1 to 4.4.0 needs to be in the 4.4 branch (maybe even the RC of 
>>> 4.4.0) or it will go in 4.4.1
>>>
>>> yes ?
>>>
 -Original Message-
 From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
 Sent: Tuesday, 17 June 2014 9:16 PM
 To: dev
 Subject: [ACS431][QUESTION] db upgrace

 In my simple mind it seems we only need to create a Upgrade430to431.java 
 file and don't need any sql files. Is this going to fly? AFAICT the only 
 thing to go in there is the vlan fixup in the vlan table, which is a data 
 migration and not a schema change.

 Can anyone point out to me the error in my ways, please?

 thanks,
 --
 Daan
>>>
>>
>>
>>
>> --
>> Daan



-- 
Daan

[ANNOUNCE] Santhosh Edukulla as a committer...

[Alex Huang]

Hi All,

The Project Management Committee (PMC) for Apache CloudStack has asked Santhosh 
Edukulla to become a committer and we are pleased to announce that he has 
accepted.

Being a committer allows many contributors to contribute more autonomously. For 
developers, it makes it easier to submit changes and eliminates the need to 
have contributions reviewed via the patch submission process. Whether 
contributions are development-related or otherwise, it is a recognition of a 
contributor's participation in the project and commitment to the project and 
the Apache Way.

Please join me in congratulating Santhosh!

--Alex, on behalf of the CloudStack PMC

Re: [ANNOUNCE] Santhosh Edukulla as a committer...

[Mike Tutkowski]

Congratulations!


On Mon, Jun 30, 2014 at 10:25 AM, Alex Huang  wrote:

> Hi All,
>
> The Project Management Committee (PMC) for Apache CloudStack has asked
> Santhosh Edukulla to become a committer and we are pleased to announce that
> he has accepted.
>
> Being a committer allows many contributors to contribute more
> autonomously. For developers, it makes it easier to submit changes and
> eliminates the need to have contributions reviewed via the patch submission
> process. Whether contributions are development-related or otherwise, it is
> a recognition of a contributor's participation in the project and
> commitment to the project and the Apache Way.
>
> Please join me in congratulating Santhosh!
>
> --Alex, on behalf of the CloudStack PMC
>



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

Re: [ANNOUNCE] Santhosh Edukulla as a committer...

[Nux!]

Congrats, Santhosh :)

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro


- Original Message -
> From: "Alex Huang" 
> To: dev@cloudstack.apache.org
> Sent: Monday, 30 June, 2014 5:25:17 PM
> Subject: [ANNOUNCE] Santhosh Edukulla as a committer...
> 
> Hi All,
> 
> The Project Management Committee (PMC) for Apache CloudStack has asked
> Santhosh Edukulla to become a committer and we are pleased to announce that
> he has accepted.
> 
> Being a committer allows many contributors to contribute more autonomously.
> For developers, it makes it easier to submit changes and eliminates the need
> to have contributions reviewed via the patch submission process. Whether
> contributions are development-related or otherwise, it is a recognition of a
> contributor's participation in the project and commitment to the project and
> the Apache Way.
> 
> Please join me in congratulating Santhosh!
> 
> --Alex, on behalf of the CloudStack PMC
> 

Re: [ANNOUNCE] Santhosh Edukulla as a committer...

[Gaurav Aradhye]

Congratulations Santhosh!

Regards,
Gaurav


On Mon, Jun 30, 2014 at 10:04 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Congratulations!
>
>
> On Mon, Jun 30, 2014 at 10:25 AM, Alex Huang 
> wrote:
>
> > Hi All,
> >
> > The Project Management Committee (PMC) for Apache CloudStack has asked
> > Santhosh Edukulla to become a committer and we are pleased to announce
> that
> > he has accepted.
> >
> > Being a committer allows many contributors to contribute more
> > autonomously. For developers, it makes it easier to submit changes and
> > eliminates the need to have contributions reviewed via the patch
> submission
> > process. Whether contributions are development-related or otherwise, it
> is
> > a recognition of a contributor's participation in the project and
> > commitment to the project and the Apache Way.
> >
> > Please join me in congratulating Santhosh!
> >
> > --Alex, on behalf of the CloudStack PMC
> >
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*
>

Re: [ANNOUNCE] Santhosh Edukulla as a committer...

[Alena Prokharchyk]

Congratulations, Santhosh!

-Alena. 

On 6/30/14, 9:25 AM, "Alex Huang"  wrote:

>Hi All,
>
>The Project Management Committee (PMC) for Apache CloudStack has asked
>Santhosh Edukulla to become a committer and we are pleased to announce
>that he has accepted.
>
>Being a committer allows many contributors to contribute more
>autonomously. For developers, it makes it easier to submit changes and
>eliminates the need to have contributions reviewed via the patch
>submission process. Whether contributions are development-related or
>otherwise, it is a recognition of a contributor's participation in the
>project and commitment to the project and the Apache Way.
>
>Please join me in congratulating Santhosh!
>
>--Alex, on behalf of the CloudStack PMC

Re: [ANNOUNCE] Santhosh Edukulla as a committer...

[Rohit Yadav]

Congrats Santhosh!

Alex Huang wrote:

Hi All,

The Project Management Committee (PMC) for Apache CloudStack has asked Santhosh 
Edukulla to become a committer and we are pleased to announce that he has 
accepted.

Being a committer allows many contributors to contribute more autonomously. For 
developers, it makes it easier to submit changes and eliminates the need to 
have contributions reviewed via the patch submission process. Whether 
contributions are development-related or otherwise, it is a recognition of a 
contributor's participation in the project and commitment to the project and 
the Apache Way.

Please join me in congratulating Santhosh!

--Alex, on behalf of the CloudStack PMC


--
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

This email and any attachments to it may be confidential and are intended solely 
for the use of the individual to whom it is addressed. Any views or opinions 
expressed are solely those of the author and do not necessarily represent those of 
Shape Blue Ltd or related companies. If you are not the intended recipient of this 
email, you must neither take any action based upon its contents, nor copy or show 
it to anyone. Please contact the sender if you believe you have received this email 
in error. Shape Blue Ltd is a company incorporated in England & Wales. 
ShapeBlue Services India LLP is a company incorporated in India and is operated 
under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company 
incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue 
is a registered trademark.

Re: [ANNOUNCE] Santhosh Edukulla as a committer...

[Jayapal Reddy Uradi]

Congrats Santhosh!

-Jayapal

On 30-Jun-2014, at 10:10 PM, Alena Prokharchyk  
wrote:

> Congratulations, Santhosh!
> 
> -Alena. 
> 
> On 6/30/14, 9:25 AM, "Alex Huang"  wrote:
> 
>> Hi All,
>> 
>> The Project Management Committee (PMC) for Apache CloudStack has asked
>> Santhosh Edukulla to become a committer and we are pleased to announce
>> that he has accepted.
>> 
>> Being a committer allows many contributors to contribute more
>> autonomously. For developers, it makes it easier to submit changes and
>> eliminates the need to have contributions reviewed via the patch
>> submission process. Whether contributions are development-related or
>> otherwise, it is a recognition of a contributor's participation in the
>> project and commitment to the project and the Apache Way.
>> 
>> Please join me in congratulating Santhosh!
>> 
>> --Alex, on behalf of the CloudStack PMC
> 

Re: [ACS4.4] pre-rc anouncment

[Chip Childers]

On Sun, Jun 29, 2014 at 03:05:48PM -0400, David Nalley wrote:
> You can delete tags and push the deletion to origin.

I stand corrected... ;-)

Secondary Storage size limits ?

[Tomasz Zięba]

Hi,

Are there known limits on Secondary Storage?
After joining 40TB SecStor, dashboard shows 0.00KB/0.00KB in System
Capacity widget.
Also, the API returns the same values.

-- 
Regards,
Tomasz Zięba
Twitter: @TZieba
LinkedIn: pl.linkedin.com/pub/tomasz-zięba-ph-d/3b/7a8/ab6/

Re: [ANNOUNCE] Santhosh Edukulla as a committer...

[Daan Hoogland]

welcome to the family and good luck,

On Mon, Jun 30, 2014 at 6:50 PM, Jayapal Reddy Uradi
 wrote:
> Congrats Santhosh!
>
> -Jayapal
>
> On 30-Jun-2014, at 10:10 PM, Alena Prokharchyk  
> wrote:
>
>> Congratulations, Santhosh!
>>
>> -Alena.
>>
>> On 6/30/14, 9:25 AM, "Alex Huang"  wrote:
>>
>>> Hi All,
>>>
>>> The Project Management Committee (PMC) for Apache CloudStack has asked
>>> Santhosh Edukulla to become a committer and we are pleased to announce
>>> that he has accepted.
>>>
>>> Being a committer allows many contributors to contribute more
>>> autonomously. For developers, it makes it easier to submit changes and
>>> eliminates the need to have contributions reviewed via the patch
>>> submission process. Whether contributions are development-related or
>>> otherwise, it is a recognition of a contributor's participation in the
>>> project and commitment to the project and the Apache Way.
>>>
>>> Please join me in congratulating Santhosh!
>>>
>>> --Alex, on behalf of the CloudStack PMC
>>
>



-- 
Daan

Re: [ACS-4.4] cherry-pick

[Daan Hoogland]

On Mon, Jun 30, 2014 at 1:21 PM, Jayapal Reddy Uradi
 wrote:
> 004d616322ba55d83407545f5b10c95ce48f75b5


I missed this one but it is in now.

-- 
Daan

Re: Review Request 23168: Update cloudstack-usage JAVA_HOME to find JRE for Java 7

[Sebastien Goasguen]

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


After the updated review it looks like you are only changing the centOS 
scripts. What about Ubuntu/debs ? is that already fixed ?

- Sebastien Goasguen


On June 30, 2014, 3:54 p.m., Olivier Lemasle wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23168/
> ---
> 
> (Updated June 30, 2014, 3:54 p.m.)
> 
> 
> Review request for cloudstack and Sebastien Goasguen.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> cloudstack-usage is currently configured to search JAVA_HOME only in a small 
> set of paths corresponding to Java 6 (/usr/lib/jvm/java-6-openjdk, 
> /usr/lib/jvm/java-6-openjdk-i386, etc).
> 
> If cloudstack-usage is installed on a server with only Java 7, the service 
> cannot start and fails with the following error:
> jsvc error: Cannot locate Java Home
> 
> This commit adds Java 7 paths to the possible set of JAVA_HOME locations.
> 
> 
> Diffs
> -
> 
>   packaging/centos63/cloud-usage.rc e78f8c1 
> 
> Diff: https://reviews.apache.org/r/23168/diff/
> 
> 
> Testing
> ---
> 
> Package CloudStack RPMs for CentOS and install them on a system with 
> java-1.7.0-openjdk and no Java 6 JRE.
> Check that cloudstack-usage works correctly.
> 
> 
> Thanks,
> 
> Olivier Lemasle
> 
>

Re: Review Request 23168: Update cloudstack-usage JAVA_HOME to find JRE for Java 7

[Olivier Lemasle]

> On June 30, 2014, 8:07 p.m., Sebastien Goasguen wrote:
> > After the updated review it looks like you are only changing the centOS 
> > scripts. What about Ubuntu/debs ? is that already fixed ?

Yes, I'm only changing the CentOS scripts.

I have no Debian server available just now, so I didn't test the .deb 
packaging, but it seems already fixed for Debian/Ubuntu:

In packaging/debian/init/cloud-usage, JDK_DIRS is set to:
/usr/lib/jvm/java-7-openjdk-amd64 /usr/lib/jvm/java-7-openjdk-i386 
/usr/lib/jvm/java-6-openjdk...

This has been set by Wido den Hollander in commit 
20070ee07f1718e1eee0f7256e3f1004116cfee8, and it includes common locations for 
OpenJDK 7 in Debian.


- Olivier


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


On June 30, 2014, 5:54 p.m., Olivier Lemasle wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/23168/
> ---
> 
> (Updated June 30, 2014, 5:54 p.m.)
> 
> 
> Review request for cloudstack and Sebastien Goasguen.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> cloudstack-usage is currently configured to search JAVA_HOME only in a small 
> set of paths corresponding to Java 6 (/usr/lib/jvm/java-6-openjdk, 
> /usr/lib/jvm/java-6-openjdk-i386, etc).
> 
> If cloudstack-usage is installed on a server with only Java 7, the service 
> cannot start and fails with the following error:
> jsvc error: Cannot locate Java Home
> 
> This commit adds Java 7 paths to the possible set of JAVA_HOME locations.
> 
> 
> Diffs
> -
> 
>   packaging/centos63/cloud-usage.rc e78f8c1 
> 
> Diff: https://reviews.apache.org/r/23168/diff/
> 
> 
> Testing
> ---
> 
> Package CloudStack RPMs for CentOS and install them on a system with 
> java-1.7.0-openjdk and no Java 6 JRE.
> Check that cloudstack-usage works correctly.
> 
> 
> Thanks,
> 
> Olivier Lemasle
> 
>

Re: [ACS4.4] RC1

[Ove Ewerlid]

On 06/30/2014 06:02 PM, Daan Hoogland wrote:

499ff73f1a14bddd81c5788930c43b2a3de099ed is the one that has the
checkstyle pom edited as well. It is on branch 4.4-RC20140630T1754.
This time I ran mvn clean test *after* running build_asf.sh threw it
away and ran the script again. Hopefully it will be alright now.
Please proof me wrong, I dare you all.


New commit id / branch fixes the checkstyle issue but yields this new error;

[ERROR] Failed to execute goal on project cloud-plugin-hypervisor-ovm: 
Could not resolve dependencies for project 
org.apache.cloudstack:cloud-plugin-hypervisor-ovm:jar:4.4.0: Failure to 
find org.apache.cloudstack:xapi:jar:6.2.0-1-SNAPSHOT in 
http://repository.apache.org/snapshots was cached in the local 
repository, resolution will not be reattempted until the update interval 
of apache.snapshots has elapsed or updates are forced -> [Help 1]


when building;

[INFO] Apache CloudStack Plugin - Hypervisor OracleVM  FAILURE [ 
0.020 s]


/Ove



Daan

On Mon, Jun 30, 2014 at 3:11 PM, Ove Ewerlid  wrote:

On 06/30/2014 02:51 PM, Daan Hoogland wrote:


Ove, to be sure I got you: Does your script need to have the branch
checked out when building a version by tag or commit-id or does it
checkout the version and then build it?



The script is setup for the historical ACS method of using a specific commit
ID to denote a release that later is turned into a tag as the vote is
passed, all using the 4.0, 4.1, 4.2, 4.3, base branch.

That being said, I noticed that the first commit ID you gave for 4.4 RC1 was
not part of the 4.4 tree. Hence, changed the build script to also support
checking out a specific "release" branch. A later 44RC1 commit id was part
of 4.4 branch.

Probably time to enhance ACS build script to use "git remote show origin"
and sieve out the branches related to a release/vote process in time order
and work on the last one.



The commit id is not on the branch 4.4 but on a branch of that called
4.4-RCT

But I noticed that you are right, the pom for checkstyle is not edited
in the release.



ok

/Ove




On Mon, Jun 30, 2014 at 1:29 PM, Ove Ewerlid 
wrote:


On 06/30/2014 11:23 AM, Daan Hoogland wrote:



This is going to be the vote thread but I read back the procedure and
found that I should more explicitly ask for consent before starting
the vote.

162ea957e6f02e56f2de7a639f4c7e593b1b3e72 is the commit id for the
version I would like to release. Do we have the feeling that this is a
version stable enough?

More specific: Citrix QA, do you have a good confidence level with the
present state of the 4.4 branch?

kind regards,



My build script experience an issue when building versus the 4.4 RC1
commit
id. The script works with "git checkout 4.4" but when doing "git checkout
" below issue occurs. The only difference (right now) is
changing "4.4-SNAPSHOT" --> "4.4.0" throughout the tree.

This Warning is issued;
[INFO] Building Apache CloudStack Maven Conventions Parent 4.4.0
[INFO]

[INFO]
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @
cloud-maven-standard ---
[WARNING] The POM for org.apache.cloudstack:checkstyle:jar:4.4.0 is
missing,
no dependency information available

Then build errors out with;

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check
(cloudstack-checkstyle) on project cloud-maven-standard: Execution
cloudstack-checkstyle of goal
org.apache.maven.plugins:maven-checkstyle-plugin\
:2.11:check failed: Plugin
org.apache.maven.plugins:maven-checkstyle-plugin:2.11 or one of its
dependencies could not be resolved: Failure to find
org.apache.cloudstack:checkstyle:jar:4.4.0 in
http://repo.maven.apache.org/maven2 was cac\
hed in the local repository, resolution will not be reattempted until the
update interval of central has elapsed or updates are forced -> [Help 1]

A usual suspect is the Maven M2 cache, the same error happens when
building
from clean cache and when building on top of a successful 4.4 build that
populates a cache sufficient for 4.4. Some 10 attempts tried, the same
issue
each time. This is with Maven v3.2.1. Build host is OEL65 with latest
updates (e.g., effectively RHEL65).

The build script handles 4.3, 4.3.0 and 4.4 without issues, just tested
that.

Thoughts?

/Ove


--
Ove Everlid
System Administrator / Architect / SDN- & Automation- & Linux-hacker
Mobile: +46706668199 (dedicated work mobile)
Country: Sweden, timezone; Middle Europan Time (MET or GMT+1)








--
Ove Everlid
System Administrator / Architect / SDN- & Automation- & Linux-hacker
Mobile: +46706668199 (dedicated work mobile)
Country: Sweden, timezone; Middle Europan Time (MET or GMT+1)







--
Ove Everlid
System Administrator / Architect / SDN- & Automation- & Linux-hacker
Mobile: +46706668199 (dedicated work mobile)
Country: Sweden, timezone; Middle Europan Time (MET or GMT+1)

Re: [ACS4.4] RC1

[Daan Hoogland]

thanks Ove,

running
$ mvn clean
$ mvn test
no errors
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 05:59 min
[INFO] Finished at: 2014-06-30T21:12:00+01:00


On Mon, Jun 30, 2014 at 9:03 PM, Ove Ewerlid  wrote:
> On 06/30/2014 06:02 PM, Daan Hoogland wrote:
>>
>> 499ff73f1a14bddd81c5788930c43b2a3de099ed is the one that has the
>> checkstyle pom edited as well. It is on branch 4.4-RC20140630T1754.
>> This time I ran mvn clean test *after* running build_asf.sh threw it
>> away and ran the script again. Hopefully it will be alright now.
>> Please proof me wrong, I dare you all.
>
>
> New commit id / branch fixes the checkstyle issue but yields this new error;
>
> [ERROR] Failed to execute goal on project cloud-plugin-hypervisor-ovm: Could
> not resolve dependencies for project
> org.apache.cloudstack:cloud-plugin-hypervisor-ovm:jar:4.4.0: Failure to find
> org.apache.cloudstack:xapi:jar:6.2.0-1-SNAPSHOT in
> http://repository.apache.org/snapshots was cached in the local repository,
> resolution will not be reattempted until the update interval of
> apache.snapshots has elapsed or updates are forced -> [Help 1]
>
> when building;
>
> [INFO] Apache CloudStack Plugin - Hypervisor OracleVM  FAILURE [ 0.020
> s]
>
> /Ove
>
>
>
>> Daan
>>
>> On Mon, Jun 30, 2014 at 3:11 PM, Ove Ewerlid 
>> wrote:
>>>
>>> On 06/30/2014 02:51 PM, Daan Hoogland wrote:


 Ove, to be sure I got you: Does your script need to have the branch
 checked out when building a version by tag or commit-id or does it
 checkout the version and then build it?
>>>
>>>
>>>
>>> The script is setup for the historical ACS method of using a specific
>>> commit
>>> ID to denote a release that later is turned into a tag as the vote is
>>> passed, all using the 4.0, 4.1, 4.2, 4.3, base branch.
>>>
>>> That being said, I noticed that the first commit ID you gave for 4.4 RC1
>>> was
>>> not part of the 4.4 tree. Hence, changed the build script to also support
>>> checking out a specific "release" branch. A later 44RC1 commit id was
>>> part
>>> of 4.4 branch.
>>>
>>> Probably time to enhance ACS build script to use "git remote show origin"
>>> and sieve out the branches related to a release/vote process in time
>>> order
>>> and work on the last one.
>>>
>>>
 The commit id is not on the branch 4.4 but on a branch of that called
 4.4-RCT

 But I noticed that you are right, the pom for checkstyle is not edited
 in the release.
>>>
>>>
>>>
>>> ok
>>>
>>> /Ove
>>>
>>>
>>>
 On Mon, Jun 30, 2014 at 1:29 PM, Ove Ewerlid 
 wrote:
>
>
> On 06/30/2014 11:23 AM, Daan Hoogland wrote:
>>
>>
>>
>> This is going to be the vote thread but I read back the procedure and
>> found that I should more explicitly ask for consent before starting
>> the vote.
>>
>> 162ea957e6f02e56f2de7a639f4c7e593b1b3e72 is the commit id for the
>> version I would like to release. Do we have the feeling that this is a
>> version stable enough?
>>
>> More specific: Citrix QA, do you have a good confidence level with the
>> present state of the 4.4 branch?
>>
>> kind regards,
>>
>
> My build script experience an issue when building versus the 4.4 RC1
> commit
> id. The script works with "git checkout 4.4" but when doing "git
> checkout
> " below issue occurs. The only difference (right now) is
> changing "4.4-SNAPSHOT" --> "4.4.0" throughout the tree.
>
> This Warning is issued;
> [INFO] Building Apache CloudStack Maven Conventions Parent 4.4.0
> [INFO]
>
> 
> [INFO]
> [INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @
> cloud-maven-standard ---
> [WARNING] The POM for org.apache.cloudstack:checkstyle:jar:4.4.0 is
> missing,
> no dependency information available
>
> Then build errors out with;
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check
> (cloudstack-checkstyle) on project cloud-maven-standard: Execution
> cloudstack-checkstyle of goal
> org.apache.maven.plugins:maven-checkstyle-plugin\
> :2.11:check failed: Plugin
> org.apache.maven.plugins:maven-checkstyle-plugin:2.11 or one of its
> dependencies could not be resolved: Failure to find
> org.apache.cloudstack:checkstyle:jar:4.4.0 in
> http://repo.maven.apache.org/maven2 was cac\
> hed in the local repository, resolution will not be reattempted until
> the
> update interval of central has elapsed or updates are forced -> [Help
> 1]
>
> A usual suspect is the Maven M2 cache, the same error happens when
> building
> from clean cache and when building on top of a successful 4.4 build
> that
> populates a cache sufficient for 4.4. Some 10 attempts tr

Re: [ANNOUNCE] Santhosh Edukulla as a committer...

[Nitin Mehta]

Congrats Santhosh. 


On 30/06/14 9:25 AM, "Alex Huang"  wrote:

>Hi All,
>
>The Project Management Committee (PMC) for Apache CloudStack has asked
>Santhosh Edukulla to become a committer and we are pleased to announce
>that he has accepted.
>
>Being a committer allows many contributors to contribute more
>autonomously. For developers, it makes it easier to submit changes and
>eliminates the need to have contributions reviewed via the patch
>submission process. Whether contributions are development-related or
>otherwise, it is a recognition of a contributor's participation in the
>project and commitment to the project and the Apache Way.
>
>Please join me in congratulating Santhosh!
>
>--Alex, on behalf of the CloudStack PMC

RE: [ANNOUNCE] Santhosh Edukulla as a committer...

[Animesh Chaturvedi]

Congrats Santhosh

> -Original Message-
> From: Alex Huang [mailto:alex.hu...@citrix.com]
> Sent: Monday, June 30, 2014 9:25 AM
> To: dev@cloudstack.apache.org
> Subject: [ANNOUNCE] Santhosh Edukulla as a committer...
> 
> Hi All,
> 
> The Project Management Committee (PMC) for Apache CloudStack has
> asked Santhosh Edukulla to become a committer and we are pleased to
> announce that he has accepted.
> 
> Being a committer allows many contributors to contribute more
> autonomously. For developers, it makes it easier to submit changes and
> eliminates the need to have contributions reviewed via the patch
> submission process. Whether contributions are development-related or
> otherwise, it is a recognition of a contributor's participation in the project
> and commitment to the project and the Apache Way.
> 
> Please join me in congratulating Santhosh!
> 
> --Alex, on behalf of the CloudStack PMC

RE: [ACS4.4] RC1

[Animesh Chaturvedi]

Daan

We have been following  the convention for Release VOTE threads like [1] as 
example.

[1] http://markmail.org/message/ksyv4gftcsjc4pma

Thanks
Animesh

> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Monday, June 30, 2014 2:23 AM
> To: dev
> Subject: [ACS4.4] RC1
> 
> This is going to be the vote thread but I read back the procedure and found
> that I should more explicitly ask for consent before starting the vote.
> 
> 162ea957e6f02e56f2de7a639f4c7e593b1b3e72 is the commit id for the
> version I would like to release. Do we have the feeling that this is a version
> stable enough?
> 
> More specific: Citrix QA, do you have a good confidence level with the
> present state of the 4.4 branch?
> 
> kind regards,
> --
> Daan

Re: 4.4 upgrade issues

[Carlos Reátegui]

Hi All,

I am having problems bringing my system back up.  I have not checked the 
credentials of my hosts but the upgraded management server is unable to connect 
to them.  Where is the password stored?

thanks.
Carlos


2014-06-30 12:55:59,277 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
(ClusteredAgentManager Timer:ctx-060c8ace) Loading directly connected host 
1(srvengxen01)
2014-06-30 12:56:04,394 DEBUG [c.c.n.l.LBHealthCheckManagerImpl] 
(LBHealthCheck-1:ctx-c6869648) LB HealthCheck Manager is running and getting 
the updates from LB providers and updating service status
2014-06-30 12:56:04,428 DEBUG [c.c.n.l.LBHealthCheckManagerImpl] 
(LBHealthCheck-1:ctx-c6869648) LB HealthCheck Manager is running and getting 
the updates from LB providers and updating service status
2014-06-30 12:56:06,844 DEBUG [c.c.h.x.r.XenServerConnectionPool] 
(ClusteredAgentManager Timer:ctx-060c8ace) Unable to create master connection 
to host(172.30.45.31) , due to The credentials given by the user are incorrect, 
so access has been denied, and you have not been issued a session handle.
2014-06-30 12:56:06,848 DEBUG [c.c.h.Status] (ClusteredAgentManager 
Timer:ctx-060c8ace) Transition:[Resource state = Enabled, Agent event = 
AgentDisconnected, Host id = 1, name = srvengxen01]
2014-06-30 12:56:06,862 WARN  [c.c.a.m.ClusteredAgentManagerImpl] 
(ClusteredAgentManager Timer:ctx-060c8ace)  can not load directly connected 
host 1(srvengxen01) due to 
com.cloud.utils.exception.CloudRuntimeException: Unable to create master 
connection to host(172.30.45.31) , due to The credentials given by the user are 
incorrect, so access has been denied, and you have not been issued a session 
handle.
at 
com.cloud.hypervisor.xen.resource.XenServerConnectionPool.getConnect(XenServerConnectionPool.java:168)
at 
com.cloud.hypervisor.xen.resource.CitrixResourceBase.CheckXenHostInfo(CitrixResourceBase.java:5722)
at 
com.cloud.hypervisor.xen.resource.CitrixResourceBase.configure(CitrixResourceBase.java:5705)
at 
com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:157)
at 
com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:672)
at 
com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:218)
at 
com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:184)
at 
com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:98)
at 
com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:234)
at 
org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30)
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.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Caused by: The credentials given by the user are incorrect, so access has been 
denied, and you have not been issued a session handle.
at com.xensource.xenapi.Types.checkResponse(Types.java:322)
at com.xensource.xenapi.Connection.dispatch(Connection.java:350)
at com.xensource.xenapi.Session.loginWithPassword(Session.java:537)
at 
com.cloud.hypervisor.xen.resource.XenServerConnectionPool.loginWithPassword(XenServerConnectionPool.java:321)
at 
com.cloud.hypervisor.xen.resource.XenServerConnectionPool.getConnect(XenServerConnectionPool.java:154)
... 17 more
2014-06-30 12:56:06,864 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
(ClusteredAgentManager Timer:ctx-060c8ace) Loading directly connected host 
2(srvengxen02)
2014-06-30 12:56:09,225 DEBUG [c.c.s.StatsCollector] 
(StatsCollector-1:ctx-8458e286) HostStatsCollector is running...
2014-06-30 12:56:09,226 DEBUG [c.c.s.StatsCollector] 
(StatsCollector-2:ctx-aa245eed) VmStatsCollector is running...
2014-06-30 12:56:09,227 DEBUG [c.c.s.StatsCollector] 
(StatsCollector-3:ctx-19894fa1) StorageCollector is running...
2014-06-30 12:56:09,230 DEBUG [c.c.s.StatsCollector] 
(StatsCollector-4:ctx-d66c71fb) AutoScaling Monitor is running...



On Jun 30, 2014, at 9:54 AM, Carlos Reátegui  wrote:

> Hi Sudha,
> Thanks for checking in.  I was out for the weekend and 

RE: [ACS4.4] RC1

[Rayees Namathponnan]

Hi Daan,

We need to remove "SNAPSHOT"  from all pom.xml before cut RC;  please see the 
script "tools/build/setnextversion.sh"

Below two issue I reported today,  second one blocking vmware automation runs 
in 4.4 

https://issues.apache.org/jira/browse/CLOUDSTACK-7011   
https://issues.apache.org/jira/browse/CLOUDSTACK-7012 


Regards,
Rayees 


-Original Message-
From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] 
Sent: Monday, June 30, 2014 12:56 PM
To: dev@cloudstack.apache.org
Subject: RE: [ACS4.4] RC1

Daan

We have been following  the convention for Release VOTE threads like [1] as 
example.

[1] http://markmail.org/message/ksyv4gftcsjc4pma

Thanks
Animesh

> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Monday, June 30, 2014 2:23 AM
> To: dev
> Subject: [ACS4.4] RC1
> 
> This is going to be the vote thread but I read back the procedure and 
> found that I should more explicitly ask for consent before starting the vote.
> 
> 162ea957e6f02e56f2de7a639f4c7e593b1b3e72 is the commit id for the 
> version I would like to release. Do we have the feeling that this is a 
> version stable enough?
> 
> More specific: Citrix QA, do you have a good confidence level with the 
> present state of the 4.4 branch?
> 
> kind regards,
> --
> Daan

Re: [ANNOUNCE] Santhosh Edukulla as a committer...

[Harikrishna Patnala]

Congratulations Santosh.


On 01-Jul-2014, at 1:16 am, Animesh Chaturvedi  
wrote:

> Congrats Santhosh
> 
>> -Original Message-
>> From: Alex Huang [mailto:alex.hu...@citrix.com]
>> Sent: Monday, June 30, 2014 9:25 AM
>> To: dev@cloudstack.apache.org
>> Subject: [ANNOUNCE] Santhosh Edukulla as a committer...
>> 
>> Hi All,
>> 
>> The Project Management Committee (PMC) for Apache CloudStack has
>> asked Santhosh Edukulla to become a committer and we are pleased to
>> announce that he has accepted.
>> 
>> Being a committer allows many contributors to contribute more
>> autonomously. For developers, it makes it easier to submit changes and
>> eliminates the need to have contributions reviewed via the patch
>> submission process. Whether contributions are development-related or
>> otherwise, it is a recognition of a contributor's participation in the 
>> project
>> and commitment to the project and the Apache Way.
>> 
>> Please join me in congratulating Santhosh!
>> 
>> --Alex, on behalf of the CloudStack PMC

RE: [ANNOUNCE] Santhosh Edukulla as a committer...

[Rayees Namathponnan]

Congrats Santosh. 

-Original Message-
From: Harikrishna Patnala [mailto:harikrishna.patn...@citrix.com] 
Sent: Monday, June 30, 2014 1:12 PM
To: 
Subject: Re: [ANNOUNCE] Santhosh Edukulla as a committer...

Congratulations Santosh.


On 01-Jul-2014, at 1:16 am, Animesh Chaturvedi  
wrote:

> Congrats Santhosh
> 
>> -Original Message-
>> From: Alex Huang [mailto:alex.hu...@citrix.com]
>> Sent: Monday, June 30, 2014 9:25 AM
>> To: dev@cloudstack.apache.org
>> Subject: [ANNOUNCE] Santhosh Edukulla as a committer...
>> 
>> Hi All,
>> 
>> The Project Management Committee (PMC) for Apache CloudStack has 
>> asked Santhosh Edukulla to become a committer and we are pleased to 
>> announce that he has accepted.
>> 
>> Being a committer allows many contributors to contribute more 
>> autonomously. For developers, it makes it easier to submit changes 
>> and eliminates the need to have contributions reviewed via the patch 
>> submission process. Whether contributions are development-related or 
>> otherwise, it is a recognition of a contributor's participation in 
>> the project and commitment to the project and the Apache Way.
>> 
>> Please join me in congratulating Santhosh!
>> 
>> --Alex, on behalf of the CloudStack PMC

Re: 4.4 upgrade issues

[Carlos Reátegui]

I found the comments in: https://issues.apache.org/jira/browse/CLOUDSTACK-3990 
useful but how do I find out the database key so that I can set the pw.

Also in looking at my previous backups for the host_details table it seems like 
the password entry changes on a regular basis.

Is there something the keeps updating the db key and re-ecrypts the host 
passwords?

On Jun 30, 2014, at 1:01 PM, Carlos Reátegui  wrote:

> Hi All,
> 
> I am having problems bringing my system back up.  I have not checked the 
> credentials of my hosts but the upgraded management server is unable to 
> connect to them.  Where is the password stored?
> 
> thanks.
> Carlos
> 
> 
> 2014-06-30 12:55:59,277 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (ClusteredAgentManager Timer:ctx-060c8ace) Loading directly connected host 
> 1(srvengxen01)
> 2014-06-30 12:56:04,394 DEBUG [c.c.n.l.LBHealthCheckManagerImpl] 
> (LBHealthCheck-1:ctx-c6869648) LB HealthCheck Manager is running and getting 
> the updates from LB providers and updating service status
> 2014-06-30 12:56:04,428 DEBUG [c.c.n.l.LBHealthCheckManagerImpl] 
> (LBHealthCheck-1:ctx-c6869648) LB HealthCheck Manager is running and getting 
> the updates from LB providers and updating service status
> 2014-06-30 12:56:06,844 DEBUG [c.c.h.x.r.XenServerConnectionPool] 
> (ClusteredAgentManager Timer:ctx-060c8ace) Unable to create master connection 
> to host(172.30.45.31) , due to The credentials given by the user are 
> incorrect, so access has been denied, and you have not been issued a session 
> handle.
> 2014-06-30 12:56:06,848 DEBUG [c.c.h.Status] (ClusteredAgentManager 
> Timer:ctx-060c8ace) Transition:[Resource state = Enabled, Agent event = 
> AgentDisconnected, Host id = 1, name = srvengxen01]
> 2014-06-30 12:56:06,862 WARN  [c.c.a.m.ClusteredAgentManagerImpl] 
> (ClusteredAgentManager Timer:ctx-060c8ace)  can not load directly connected 
> host 1(srvengxen01) due to 
> com.cloud.utils.exception.CloudRuntimeException: Unable to create master 
> connection to host(172.30.45.31) , due to The credentials given by the user 
> are incorrect, so access has been denied, and you have not been issued a 
> session handle.
>at 
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.getConnect(XenServerConnectionPool.java:168)
>at 
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.CheckXenHostInfo(CitrixResourceBase.java:5722)
>at 
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.configure(CitrixResourceBase.java:5705)
>at 
> com.cloud.resource.DiscovererBase.reloadResource(DiscovererBase.java:157)
>at 
> com.cloud.agent.manager.AgentManagerImpl.loadDirectlyConnectedHost(AgentManagerImpl.java:672)
>at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.scanDirectAgentToLoad(ClusteredAgentManagerImpl.java:218)
>at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.runDirectAgentScanTimerTask(ClusteredAgentManagerImpl.java:184)
>at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl.access$100(ClusteredAgentManagerImpl.java:98)
>at 
> com.cloud.agent.manager.ClusteredAgentManagerImpl$DirectAgentScanTimerTask.runInContext(ClusteredAgentManagerImpl.java:234)
>at 
> org.apache.cloudstack.managed.context.ManagedContextTimerTask$1.runInContext(ManagedContextTimerTask.java:30)
>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.managed.context.ManagedContextTimerTask.run(ManagedContextTimerTask.java:27)
>at java.util.TimerThread.mainLoop(Timer.java:555)
>at java.util.TimerThread.run(Timer.java:505)
> Caused by: The credentials given by the user are incorrect, so access has 
> been denied, and you have not been issued a session handle.
>at com.xensource.xenapi.Types.checkResponse(Types.java:322)
>at com.xensource.xenapi.Connection.dispatch(Connection.java:350)
>at com.xensource.xenapi.Session.loginWithPassword(Session.java:537)
>at 
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.loginWithPassword(XenServerConnectionPool.java:321)
>at 
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.getConnect(XenServerConnectionPool.java:154)
>... 17 more
> 2014-06-30 12:56:06,864 DEBUG [c.c.a.m.ClusteredAgentManagerImpl] 
> (ClusteredAgentManager Timer:ctx-060c8ace) Loading directly connected host 
> 2(srvengxen02)
> 2014-06-30 12:56:09,225 DEBUG [c.c.s

[ACS431] Jira issues

[sebgoa]

Folks,

I am spending a couple minutes on jira tonight :) looking for bugs that are 
reported in 4.3.0 and may have been fixed in master but not cherry picked..

We have a lot of bugs…

It would be nice if everyone could spend 20 minutes browsing through JIRA and 
close issues that they know about. I already closed a few, I also see 
duplicates, I see support requests etc…My guess is we would cut down 
drastically our bug count if everyone were to spend 20 minutes on jira a day 
(including users).

If you do it and see something that should be picked to 4.3.1 , please email me.

-Sebastien

Re: Review Request 22721: removed hard coded jdk_dirs in cloud-usage script

[Sebastien Goasguen]

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


Seems I can take that to 4.3.1 as well ?

- Sebastien Goasguen


On June 18, 2014, 10:15 a.m., Rajani Karuturi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22721/
> ---
> 
> (Updated June 18, 2014, 10:15 a.m.)
> 
> 
> Review request for cloudstack, Kishan Kavala and Rayees Namathponnan.
> 
> 
> Bugs: CLOUDSTACK-6926
> https://issues.apache.org/jira/browse/CLOUDSTACK-6926
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> used to readlink -e and dirname to get the JAVA_HOME
> if JAVA_HOME is not already defined, sets it to jdk home if javac is present 
> else jre home if java is present.
> if nothing is present, it exits with error
> 
> 
> Diffs
> -
> 
>   packaging/centos63/cloud-usage.rc 6170379 
>   packaging/debian/init/cloud-usage 1cc75cc 
> 
> Diff: https://reviews.apache.org/r/22721/diff/
> 
> 
> Testing
> ---
> 
> 
> tested it when java is not installed, jre is installed, jdk installed or when 
> a older version is installed on centos 6.4 and ubuntu 14.04 
> 
> 
> Thanks,
> 
> Rajani Karuturi
> 
>

Re: Review Request 22194: Fixed Resource leak reported by coverity

[Sebastien Goasguen]

> On June 3, 2014, 12:11 p.m., Koushik Das wrote:
> > master -> 793462e5fa40dc73ce30658fe6a27e4284ed9cdb
> > 4.4-forward -> d511847cfedad5478d1b4087c8f97be2c5bf3cc8

can I pick it for 4.3.1 ?


- Sebastien


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


On June 3, 2014, 10:42 a.m., Rajani Karuturi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22194/
> ---
> 
> (Updated June 3, 2014, 10:42 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Koushik Das, and Santhosh 
> Edukulla.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixed Resource leak (RESOURCE_LEAK)
> 11. overwrite_var: Overwriting "pstmt" in "pstmt = 
> conn.prepareStatement("INSERT INTO `cloud`.`ldap_configuration`(hostname, 
> port) VALUES(?,?)")" leaks the resource that "pstmt" refers to.
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java 7e26132 
> 
> Diff: https://reviews.apache.org/r/22194/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rajani Karuturi
> 
>

Re: 4.4 upgrade issues

[Carlos Reátegui]

Making a little progress but still stuck…

I realized that when I did the upgrade it had asked me if to keep the old 
dp.properties or use the new one.  The structure of the file seemed different 
enough and I did not recall using anything but the defaults so I went ahead and 
told it to use the new one.  Seems this was not the right thing to do.

I have updated the password/ecryption settings to match the old file but it is 
still not working.  Now I am getting stuck here:

2014-06-30 13:50:32,139 DEBUG [c.c.s.d.VMTemplateDaoImpl] (main:null) Found 
parameter routing unique name null
2014-06-30 13:50:32,139 DEBUG [c.c.s.d.VMTemplateDaoImpl] (main:null) Use 
console proxy template : routing
2014-06-30 13:50:32,143 INFO  [c.c.u.d.GenericDaoBase] (main:null) Cache 
created: [ name = HostPodDaoImpl status = STATUS_ALIVE eternal = false 
overflowToDisk = false maxEntriesLocalHeap = 50 maxEntriesLocalDisk = 0 
memoryStoreEvictionPolicy = LRU timeToLiveSeconds = 600 timeToIdleSeconds = 300 
persistence = none diskExpiryThreadIntervalSeconds = 120 cacheEventListeners: 
net.sf.ehcache.statistics.LiveCacheStatisticsWrapper  hitCount = 0 
memoryStoreHitCount = 0 diskStoreHitCount = 0 missCountNotFound = 0 
missCountExpired = 0 maxBytesLocalHeap = 0 overflowToOffHeap = false 
maxBytesLocalOffHeap = 0 maxBytesLocalDisk = 0 pinned = false ]
2014-06-30 13:50:32,157 INFO  [c.c.u.d.GenericDaoBase] (main:null) Cache 
created: [ name = DedicatedResourceDaoImpl status = STATUS_ALIVE eternal = 
false overflowToDisk = false maxEntriesLocalHeap = 30 maxEntriesLocalDisk = 0 
memoryStoreEvictionPolicy = LRU timeToLiveSeconds = 3600 timeToIdleSeconds = 
300 persistence = none diskExpiryThreadIntervalSeconds = 120 
cacheEventListeners: net.sf.ehcache.statistics.LiveCacheStatisticsWrapper  
hitCount = 0 memoryStoreHitCount = 0 diskStoreHitCount = 0 missCountNotFound = 
0 missCountExpired = 0 maxBytesLocalHeap = 0 overflowToOffHeap = false 
maxBytesLocalOffHeap = 0 maxBytesLocalDisk = 0 pinned = false ]
2014-06-30 13:50:32,168 INFO  [c.c.u.d.GenericDaoBase] (main:null) Cache 
created: [ name = HypervisorCapabilitiesDaoImpl status = STATUS_ALIVE eternal = 
false overflowToDisk = false maxEntriesLocalHeap = 100 maxEntriesLocalDisk = 0 
memoryStoreEvictionPolicy = LRU timeToLiveSeconds = 600 timeToIdleSeconds = 300 
persistence = none diskExpiryThreadIntervalSeconds = 120 cacheEventListeners: 
net.sf.ehcache.statistics.LiveCacheStatisticsWrapper  hitCount = 0 
memoryStoreHitCount = 0 diskStoreHitCount = 0 missCountNotFound = 0 
missCountExpired = 0 maxBytesLocalHeap = 0 overflowToOffHeap = false 
maxBytesLocalOffHeap = 0 maxBytesLocalDisk = 0 pinned = false ]
2014-06-30 13:50:32,175 INFO  [c.c.u.d.GenericDaoBase] (main:null) Cache 
created: [ name = UserDaoImpl status = STATUS_ALIVE eternal = false 
overflowToDisk = false maxEntriesLocalHeap = 5000 maxEntriesLocalDisk = 0 
memoryStoreEvictionPolicy = LRU timeToLiveSeconds = 300 timeToIdleSeconds = 300 
persistence = none diskExpiryThreadIntervalSeconds = 120 cacheEventListeners: 
net.sf.ehcache.statistics.LiveCacheStatisticsWrapper  hitCount = 0 
memoryStoreHitCount = 0 diskStoreHitCount = 0 missCountNotFound = 0 
missCountExpired = 0 maxBytesLocalHeap = 0 overflowToOffHeap = false 
maxBytesLocalOffHeap = 0 maxBytesLocalDisk = 0 pinned = false ]
2014-06-30 13:50:32,180 INFO  [c.c.u.d.GenericDaoBase] (main:null) Cache 
created: [ name = ServiceOfferingDaoImpl status = STATUS_ALIVE eternal = false 
overflowToDisk = false maxEntriesLocalHeap = 50 maxEntriesLocalDisk = 0 
memoryStoreEvictionPolicy = LRU timeToLiveSeconds = 600 timeToIdleSeconds = 300 
persistence = none diskExpiryThreadIntervalSeconds = 120 cacheEventListeners: 
net.sf.ehcache.statistics.LiveCacheStatisticsWrapper  hitCount = 0 
memoryStoreHitCount = 0 diskStoreHitCount = 0 missCountNotFound = 0 
missCountExpired = 0 maxBytesLocalHeap = 0 overflowToOffHeap = false 
maxBytesLocalOffHeap = 0 maxBytesLocalDisk = 0 pinned = false ]
2014-06-30 13:50:32,187 INFO  [c.c.u.d.GenericDaoBase] (main:null) Cache 
created: [ name = DataCenterDaoImpl status = STATUS_ALIVE eternal = false 
overflowToDisk = false maxEntriesLocalHeap = 50 maxEntriesLocalDisk = 0 
memoryStoreEvictionPolicy = LRU timeToLiveSeconds = 600 timeToIdleSeconds = 300 
persistence = none diskExpiryThreadIntervalSeconds = 120 cacheEventListeners: 
net.sf.ehcache.statistics.LiveCacheStatisticsWrapper  hitCount = 0 
memoryStoreHitCount = 0 diskStoreHitCount = 0 missCountNotFound = 0 
missCountExpired = 0 maxBytesLocalHeap = 0 overflowToOffHeap = false 
maxBytesLocalOffHeap = 0 maxBytesLocalDisk = 0 pinned = false ]
2014-06-30 13:50:32,188 INFO  [c.c.u.d.GenericDaoBase] (main:null) Cache 
created: [ name = Ip Alloc status = STATUS_ALIVE eternal = false overflowToDisk 
= false maxEntriesLocalHeap = 50 maxEntriesLocalDisk = 0 
memoryStoreEvictionPolicy = LRU timeToLiveSeconds = 600 timeToIdleSeconds = 300 
persistence = none diskExpiryThreadIntervalSeconds = 120 cacheEventL

Re: [DISCUSS][PROPOSAL] git workflow

[Sebastien Goasguen]

I would like to re-start this discussion.

Rajani made some good points and someone mentioned Gitflow:

http://nvie.com/posts/a-successful-git-branching-model/

Thinking about our release procedure, we clearly need more tests and a CI. 
However it looks like this is going to take some time.

In the meantime I think there is nothing preventing us from agreeing to 'git 
practices', we don't need tests or new infra, we just need to agree on the git 
workflow.

Right now Master is really a development branch, we should make it a stable 
branch for production with very few commits.
This does not mean that we would release less, in contrary this would ensure 
that a commit to master means it's a production release.

In addition gitflow [1] does not do cherry-picks (gets back to Rajani's point) 
everything is based on merges.

I am of the opinion that git flow provides a nice process. It basically freezes 
master. Development happens in a 'develop' branch, releases branches are 
branched off of that and merged into master and back into develop….etc

Please read [1] it's a good read.

And let's discuss,

[1] http://nvie.com/posts/a-successful-git-branching-model/

-Sebastien

On Jun 2, 2014, at 11:58 PM, Rajani Karuturi  wrote:

> There is also the problem of cherry-picking.
> As a contributor, I always endup creating multiple patches for each branch as 
> they don’t cleanly apply on the upward branches. which means distinct commits 
> for each branch and I don’t easily know which all branches my commit exists 
> unless I do grep.
> if we follow merging strategy properly, apart from the first merge of the 
> branch, everything else on top of it should be a painless merge. 
> 
> 
> 
> ~Rajani
> 
> 
> 
> On 02-Jun-2014, at 10:51 pm, Marcus  wrote:
> 
>> I think many of the bullet points are what we are currently doing
>> (guidelines for commit comments, feature branches need to stay in sync with
>> master, no back-merging). I also think that much of what we do now is done
>> the way it is simply because there *are* vast changes between versions.
>> Classes are getting shuffled around and changed all the time. If its
>> feasible to merge branch fixes to master, that's fine, but some quick tests
>> seem to indicate that this will be messy getting started.
>> 
>> That leaves us with how we do releases. I'm fine with having single
>> branches for major releases(4.3) and tagging the commits where each
>> incremental release (4.3.x) is done. I'm trying to remember why we went
>> with the -forward, I'm sure it's in the mailing list somewhere, but one of
>> the nice things it provides is the ability for the release manager to
>> control what changes are made during code freeze while giving people a
>> place to stage fixes (though admittedly this is not always followed).
>> Without -forward, would the flow be for each dev to have their own repo and
>> issue pull requests for bugfixes?
>> 
>> 
>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi 
>> wrote:
>> 
>>> Any other suggestions/objections/comments??
>>> Can we discuss this in detail and agree to a process??
>>> 
>>> 
>>> ~Rajani
>>> 
>>> 
>>> 
>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi 
>>> wrote:
>>> 
 Yes as mike said, if its a one-off case we can do a empty merge(merge -s
>>> ours) for it and git will assume its merged but will not bring in any
>>> changes.
 
 If the branches diverged a lot, for example after a major rewrite, we
>>> could stop merging to that branch and above and make the fix manually.
 
 
 ~Rajani
 
 
 
 On 30-May-2014, at 11:26 pm, Mike Tutkowski <
>>> mike.tutkow...@solidfire.com> wrote:
 
> Yep, that's what I was referring to in that a particular fix for an old
> release may not apply to newer versions. That does happen.
> 
> We used to mark those as "don't need to merge to branch x" in SVN and
>>> then
> you handed it however made sense on the applicable branch(es).
> 
> 
> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
>>> stephen.tur...@citrix.com>
> wrote:
> 
>> What happens if a fix isn't relevant for newer versions, or has to be
>> rewritten for newer versions because the code has changed? Don't the
>> branches diverge and you end up cherry-picking after that?
>> 
>> --
>> Stephen Turner
>> 
>> 
>> -Original Message-
>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> Sent: 30 May 2014 18:48
>> To: dev@cloudstack.apache.org
>> Subject: Re: [PROPOSAL] git workflow
>> 
>> I think this flow is something we should seriously consider.
>> 
>> I find cherry picking from branch to branch to be error prone in that
>>> it's
>> easy for someone to forget to cherry pick to all applicable branches
>>> and
>> you don't have any easy way to see the cherry picks are related.
>> 
>> When I worked at HP, we had automated tools check to see if you
>>> checked a
>>>

Re: [ANNOUNCE] Santhosh Edukulla as a committer...

[Amogh Vasekar]

Congrats Santhosh!

On 6/30/14 1:14 PM, "Rayees Namathponnan" 
wrote:

>Congrats Santosh. 
>
>-Original Message-
>From: Harikrishna Patnala [mailto:harikrishna.patn...@citrix.com]
>Sent: Monday, June 30, 2014 1:12 PM
>To: 
>Subject: Re: [ANNOUNCE] Santhosh Edukulla as a committer...
>
>Congratulations Santosh.
>
>
>On 01-Jul-2014, at 1:16 am, Animesh Chaturvedi
> wrote:
>
>> Congrats Santhosh
>> 
>>> -Original Message-
>>> From: Alex Huang [mailto:alex.hu...@citrix.com]
>>> Sent: Monday, June 30, 2014 9:25 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: [ANNOUNCE] Santhosh Edukulla as a committer...
>>> 
>>> Hi All,
>>> 
>>> The Project Management Committee (PMC) for Apache CloudStack has
>>> asked Santhosh Edukulla to become a committer and we are pleased to
>>> announce that he has accepted.
>>> 
>>> Being a committer allows many contributors to contribute more
>>> autonomously. For developers, it makes it easier to submit changes
>>> and eliminates the need to have contributions reviewed via the patch
>>> submission process. Whether contributions are development-related or
>>> otherwise, it is a recognition of a contributor's participation in
>>> the project and commitment to the project and the Apache Way.
>>> 
>>> Please join me in congratulating Santhosh!
>>> 
>>> --Alex, on behalf of the CloudStack PMC
>

vhd-util location

[Carlos Reátegui]

Hi All,

When does stuff get copied from [1] to [2] ?

I ask because the docs 
(http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/latest/installation.html)
 say to download vhd-util and place it in [1] however the script that pushes it 
to the hosts looks for it in [2].  

In my case I don’t recall at when I placed it in [1], if it was in the order 
described in the install docs or if it was after I realized it had not been 
deployed to my hosts and did it manually.

Is this a bug?  

[1] /usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver 
[2] 
/usr/share/cloudstack-management/webapps/client/WEB-INF/classes/scripts/vm/hypervisor/xenserver

Re: 4.4 upgrade issues

[Carlos Reátegui]

I set encryption to none in db.properties and updated the passwords in 
host_details to unencrypted versions so I could make progress. 

I don’t know what exactly the problem was but this is probably something that 
needs better testing.  I’m pretty sure I had all the encryption stuff correct 
in the db.properties file but could not get it to work.

It would be nice if there was a specialized merging utility for the 
db.properties given the change in the organization of the file.  I am guessing 
if the file had not been reorganized it would have been more obvious how to 
merge the 2 and I may have avoided this issue. 

Now my hosts come up in an alert state and I’m not sure where to go from here.  
Please note I am not using bridge mode because I wanted to to a 4 nic bridge 
which bridge does not allow (only 2 nics).  This was working fine in 4.1 so 
hopefully this is not a requirement for 4.4.  I am not using security groups 
which was my understanding is what requires bridge networking:

The error in the log is this:
2014-06-30 14:06:50,073 WARN  [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-1:ctx-35941dc7) Failed to configure brige firewall
2014-06-30 14:06:50,073 WARN  [c.c.h.x.r.CitrixResourceBase] 
(DirectAgent-1:ctx-35941dc7) Check host 172.30.45.32 for CSP is installed or 
not and check network mode for bridge
2014-06-30 14:06:50,074 DEBUG [c.c.a.m.DirectAgentAttache] 
(DirectAgent-1:ctx-35941dc7) Seq 2-6232418934327345153: Response Received: 
2014-06-30 14:06:50,075 DEBUG [c.c.a.t.Request] (DirectAgent-1:ctx-35941dc7) 
Seq 2-6232418934327345153: Processing:  { Ans: , MgmtId: 233845174730253, via: 
2, Ver: v1, Flags: 110, [{"com.cloud.agent.api
.SetupAnswer":{"_reconnect":true,"result":false,"details":"Failed to configure 
brige firewall","wait":0}}] }
2014-06-30 14:06:50,075 DEBUG [c.c.a.t.Request] (AgentTaskPool-2:ctx-b360d1bb) 
Seq 2-6232418934327345153: Received:  { Ans: , MgmtId: 233845174730253, via: 2, 
Ver: v1, Flags: 110, { SetupAnswer } }
2014-06-30 14:06:50,076 DEBUG [c.c.a.m.AgentAttache] 
(DirectAgent-1:ctx-35941dc7) Seq 2-6232418934327345153: No more commands found
2014-06-30 14:06:50,076 WARN  [c.c.h.x.d.XcpServerDiscoverer] 
(AgentTaskPool-2:ctx-b360d1bb) Unable to setup agent 2 due to Failed to 
configure brige firewall
2014-06-30 14:06:50,079 INFO  [c.c.u.e.CSExceptionErrorCode] 
(AgentTaskPool-2:ctx-b360d1bb) Could not find exception: 
com.cloud.exception.ConnectionException in error code list for exceptions
2014-06-30 14:06:50,079 WARN  [c.c.a.m.AgentManagerImpl] 
(AgentTaskPool-2:ctx-b360d1bb) Monitor XcpServerDiscoverer says there is an 
error in the connect process for 2 due to Reinitialize agent after se
tup.
2014-06-30 14:06:50,079 INFO  [c.c.a.m.AgentManagerImpl] 
(AgentTaskPool-2:ctx-b360d1bb) Host 2 is disconnecting with event 
AgentDisconnected
2014-06-30 14:06:50,085 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentTaskPool-2:ctx-b360d1bb) The next status of agent 2is Alert, current 
status is Connecting
2014-06-30 14:06:50,085 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentTaskPool-2:ctx-b360d1bb) Deregistering link for 2 with state Alert
2014-06-30 14:06:50,085 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentTaskPool-2:ctx-b360d1bb) Remove Agent : 2
2014-06-30 14:06:50,085 DEBUG [c.c.a.m.DirectAgentAttache] 
(AgentTaskPool-2:ctx-b360d1bb) Processing disconnect 2(srvengxen02)
2014-06-30 14:06:50,085 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentTaskPool-2:ctx-b360d1bb) Sending Disconnect to listener: 
com.cloud.hypervisor.xen.discoverer.XcpServerDiscoverer
2014-06-30 14:06:50,085 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentTaskPool-2:ctx-b360d1bb) Sending Disconnect to listener: 
com.cloud.hypervisor.hyperv.discoverer.HypervServerDiscoverer
2014-06-30 14:06:50,085 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentTaskPool-2:ctx-b360d1bb) Sending Disconnect to listener: 
org.apache.cloudstack.engine.orchestration.NetworkOrchestrator
2014-06-30 14:06:50,086 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentTaskPool-2:ctx-b360d1bb) Sending Disconnect to listener: 
com.cloud.network.security.SecurityGroupListener
2014-06-30 14:06:50,086 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentTaskPool-2:ctx-b360d1bb) Sending Disconnect to listener: 
com.cloud.vm.ClusteredVirtualMachineManagerImpl
2014-06-30 14:06:50,086 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentTaskPool-2:ctx-b360d1bb) Sending Disconnect to listener: 
com.cloud.storage.secondary.SecondaryStorageListener
2014-06-30 14:06:50,086 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentTaskPool-2:ctx-b360d1bb) Sending Disconnect to listener: 
com.cloud.deploy.DeploymentPlanningManagerImpl
2014-06-30 14:06:50,086 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentTaskPool-2:ctx-b360d1bb) Sending Disconnect to listener: 
com.cloud.storage.listener.StoragePoolMonitor
2014-06-30 14:06:50,086 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentTaskPool-2:ctx-b360d1bb) Sending Disconnect to listener: 
com.cloud.storage.download.DownloadListener
2014-06-30 14:06:50,086 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentTaskPool-2:ctx-b36

Re: Review Request 22799: Golden (Base) Primary Storage feature

[Hieu LE]

Tim,

How can I monitor/watch the process of read-cache feature in XenServer
Creedence Alpha 2 ?


On Thu, Jun 26, 2014 at 10:51 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Thanks! I'm also curious about manual (or automated) regression testing
> you may have performed.
>
>
> On Wed, Jun 25, 2014 at 7:52 PM, Hieu LE  wrote:
>
>> Hi Tim and Mike,
>>
>>
>> On Tue, Jun 24, 2014 at 7:30 PM, Tim Mackey  wrote:
>>
>>> Hieu,
>>>
>>> It would also be good in your design doc and testing to validate which
>>> XenServer versions you expect this to work with, and don't forget about
>>> xcp-xapi in pure Linux as part of that.  If you have time, I'd also be
>>> curious if XenServer Creedence Read cache has any impact on your
>>> results/implementation.  That was part of the alpha.2 drop.
>>>
>>> -tim
>>>
>>
>> Thank you Tim, I have forgotten xcp-xapi. Otherwise, XenServer version is
>> 6.2.0 with thin-provisioning enabled.
>>
>> XenServer Creedence Read cache is nice, and I am testing it :-). Will
>> report soon.
>>
>>
>>>
>>> On Mon, Jun 23, 2014 at 11:24 PM, Mike Tutkowski <
>>> mike.tutkow...@solidfire.com> wrote:
>>>
 Hi,

 Yes, Marvin is great for automated regression testing of CloudStack.

 However, I was hoping you could note even manual testing (new and
 regression tests) you may have run to verify correctness of the system
 within reason (even if these are not automated).

 If you have time, automated tests would be excellent, as well.

 Thanks!
 Mike


>> Mike,
>>
>> I will update the manual test case cover in review board soon. I am also
>> re-running all test to ensure this feature running well.
>>
>>
>>>
 On Mon, Jun 23, 2014 at 8:50 PM, Hieu LE  wrote:

> Hi Tim and Mike,
>
>
> On Tue, Jun 24, 2014 at 5:59 AM, Tim Mackey  wrote:
>
>>This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/22799/
>>
>> On June 23rd, 2014, 9:16 p.m. UTC, *Mike Tutkowski* wrote:
>>
>> I was wondering if you could fill out the section about tests that have 
>> been performed?
>>
>> I would be interested in both new and regression testing.
>>
>> Thanks!
>>
>> Thank you Mike, will I use marvin for regression testing ?
>
>
>>   It looked like some functions added parameters, but didn't include 
>> descriptions of those parameters.
>>
>> Having just gone through some refactoring, I'd like to see some of the 
>> abbreviations made clearer.  I'm thinking of future people who might not 
>> be as familiar with this code.
>>
>> Thank you, I will refactor my code to make it clearer.
>
>
>>
>>
>> You made changes to schema-421to430, but that represents shipping 
>> versions.  Please ensure schema changes are done in 4.5 (aka master).
>>
>> Sure !
>
>> I didn't see anything which limited this to XenServer only.  I could 
>> easily have missed it, but if this is only XenServer, I'd prefer to see 
>> some check to keep people from accidentally configuring something which 
>> isn't expected to work for them.
>>
>> I have implemented some checks in this patch which limited to
> XenServer, e.g: in DeploymentPlanningManagerImpl class, function
> planBaseDeployment, line 298, or basePsHostCheck function to check that
> host can communicate with pool.
>
>
>>
>>
>> Thanks
>>
>> -tim
>>
>>
>> - Tim
>>
>> On June 20th, 2014, 3:46 a.m. UTC, Hieu LE wrote:
>>Review request for cloudstack, Mike Tutkowski and Tim Mackey.
>> By Hieu LE.
>>
>> *Updated June 20, 2014, 3:46 a.m.*
>>  *Repository: * cloudstack-git
>> Description
>>
>> As discussed in mailing list, this patch is applied for golden primary 
>> storage in [1].
>> I have changed the term from "golden" to "base" because there are some 
>> functions and variables in CloudStack also use "base" for base image.
>> This patch only apply for Xen Server.
>>
>> [1]: 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Golden+Primary+Storage
>>
>>   Diffs
>>
>>- api/src/com/cloud/deploy/DeployDestination.java
>>(4ded5ebe7a18252da471ee25019856f2b2f772e0)
>>- api/src/com/cloud/storage/StoragePool.java
>>(8e03c3348f3a6dd3156ab9e440126ea317957dc0)
>>- api/src/com/cloud/template/VirtualMachineTemplate.java
>>(599212bb039fdbb78511019e8f0a6ea4b4a84440)
>>- api/src/org/apache/cloudstack/api/ApiConstants.java
>>(ae5d6f05b6b52f60b151369a641cb11fcbb558af)
>>- api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java
>>(2350f6b389203e2c6cc2182fe03fe9a95e936b81)
>>- 
>> api/src/org/apache/cloudstack/api/command/admin/storage/CreateStoragePoolCmd.java
>>(ae44bc9373232d242e4ebdcf76844969

RE: [ANNOUNCE] Santhosh Edukulla as a committer...

[Rajesh Battala]

Hearty Congratulations Santosh :)

-Original Message-
From: Alex Huang [mailto:alex.hu...@citrix.com] 
Sent: Monday, June 30, 2014 9:55 PM
To: dev@cloudstack.apache.org
Subject: [ANNOUNCE] Santhosh Edukulla as a committer...

Hi All,

The Project Management Committee (PMC) for Apache CloudStack has asked Santhosh 
Edukulla to become a committer and we are pleased to announce that he has 
accepted.

Being a committer allows many contributors to contribute more autonomously. For 
developers, it makes it easier to submit changes and eliminates the need to 
have contributions reviewed via the patch submission process. Whether 
contributions are development-related or otherwise, it is a recognition of a 
contributor's participation in the project and commitment to the project and 
the Apache Way.

Please join me in congratulating Santhosh!

--Alex, on behalf of the CloudStack PMC

Re: [ANNOUNCE] Santhosh Edukulla as a committer...

[Abhinandan Prateek]

Congrats, Santhosh !

On 30/06/14 9:55 pm, "Alex Huang"  wrote:

>Hi All,
>
>The Project Management Committee (PMC) for Apache CloudStack has asked
>Santhosh Edukulla to become a committer and we are pleased to announce
>that he has accepted.
>
>Being a committer allows many contributors to contribute more
>autonomously. For developers, it makes it easier to submit changes and
>eliminates the need to have contributions reviewed via the patch
>submission process. Whether contributions are development-related or
>otherwise, it is a recognition of a contributor's participation in the
>project and commitment to the project and the Apache Way.
>
>Please join me in congratulating Santhosh!
>
>--Alex, on behalf of the CloudStack PMC

[ACS4.4] Text change to cherry pick if it's not too late

[Mike Tutkowski]

Hi Daan,

Speaking of low-risk fixes for 4.4, I have one:

76930f6eab01d8659b71e5753111de52eca73b5b

I noticed a label of "label.cache.mode" in the Add Disk Offering dialog.

I tracked it down to a missing line in dictionary.jsp.

If it's not too late, please cherry pick to 4.4.

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

RE: [ANNOUNCE] Santhosh Edukulla as a committer...

[Koushik Das]

Congrats Santhosh!

-Original Message-
From: Alex Huang [mailto:alex.hu...@citrix.com] 
Sent: Monday, 30 June 2014 9:55 PM
To: dev@cloudstack.apache.org
Subject: [ANNOUNCE] Santhosh Edukulla as a committer...

Hi All,

The Project Management Committee (PMC) for Apache CloudStack has asked Santhosh 
Edukulla to become a committer and we are pleased to announce that he has 
accepted.

Being a committer allows many contributors to contribute more autonomously. For 
developers, it makes it easier to submit changes and eliminates the need to 
have contributions reviewed via the patch submission process. Whether 
contributions are development-related or otherwise, it is a recognition of a 
contributor's participation in the project and commitment to the project and 
the Apache Way.

Please join me in congratulating Santhosh!

--Alex, on behalf of the CloudStack PMC

Re: [ACS4.5] Can't access volumes on storage tab in GUI

[Mike Tutkowski]

I looked into this a bit more.

It appears that the "volume_view" no longer has the following two columns:

vm_template.name template_name
vm_template.display_text template_display_text

The problem is that the Java class, VolumeJoinVO, still has reference to
them (a variable for each one).

I would just remove these variables; however, they are still in use as they
are returned to clients as responses (at least we try to return them, but
get an exception before being able to do so).

If we really want to remove these two columns, that will mean breaking the
API, which really should wait until a major release.


On Mon, Jun 30, 2014 at 9:07 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Thanks for the reply.
>
> The weird part is that this is the second time I've recreated the DB and
> seen this issue.
>
> If I have time a bit later, I can see if the SQL in Git is wrong and
> update it with what you provided.
>
> Thanks!
>
>
> On Mon, Jun 30, 2014 at 5:47 AM, Bharat Kumar 
> wrote:
>
>> Hi Mike,
>>
>> I think the volume_view did not get created properly for some reason. I
>> think recreating the volume_view will fix the problem.
>>
>> below commas should fix the issue.
>>
>> DROP VIEW IF EXISTS `cloud`.`volume_view`;
>> CREATE VIEW `cloud`.`volume_view` AS
>> select
>> volumes.id,
>> volumes.uuid,
>> volumes.name,
>> volumes.device_id,
>> volumes.volume_type,
>> volumes.size,
>> volumes.min_iops,
>> volumes.max_iops,
>> volumes.created,
>> volumes.state,
>> volumes.attached,
>> volumes.removed,
>> volumes.pod_id,
>> volumes.display_volume,
>> volumes.format,
>> volumes.path,
>> volumes.chain_info,
>> account.id account_id,
>> account.uuid account_uuid,
>> account.account_name account_name,
>> account.type account_type,
>> domain.id domain_id,
>> domain.uuid domain_uuid,
>> domain.name domain_name,
>> domain.path domain_path,
>> projects.id project_id,
>> projects.uuid project_uuid,
>> projects.name project_name,
>> data_center.id data_center_id,
>> data_center.uuid data_center_uuid,
>> data_center.name data_center_name,
>> data_center.networktype data_center_type,
>> vm_instance.id vm_id,
>> vm_instance.uuid vm_uuid,
>> vm_instance.name vm_name,
>> vm_instance.state vm_state,
>> vm_instance.vm_type,
>> user_vm.display_name vm_display_name,
>> volume_store_ref.size volume_store_size,
>> volume_store_ref.download_pct,
>> volume_store_ref.download_state,
>> volume_store_ref.error_str,
>> volume_store_ref.created created_on_store,
>> disk_offering.id disk_offering_id,
>> disk_offering.uuid disk_offering_uuid,
>> disk_offering.name disk_offering_name,
>> disk_offering.display_text disk_offering_display_text,
>> disk_offering.use_local_storage,
>> disk_offering.system_use,
>> disk_offering.bytes_read_rate,
>> disk_offering.bytes_write_rate,
>> disk_offering.iops_read_rate,
>> disk_offering.iops_write_rate,
>> disk_offering.cache_mode,
>> storage_pool.id pool_id,
>> storage_pool.uuid pool_uuid,
>> storage_pool.name pool_name,
>> cluster.hypervisor_type,
>> vm_template.id template_id,
>> vm_template.uuid template_uuid,
>> vm_template.extractable,
>> vm_template.type template_type,
>> vm_template.name template_name,
>> vm_template.display_text template_display_text,
>> iso.id iso_id,
>> iso.uuid iso_uuid,
>> iso.name iso_name,
>> iso.display_text iso_display_text,
>> resource_tags.id tag_id,
>> resource_tags.uuid tag_uuid,
>> resource_tags.key tag_key,
>> resource_tags.value tag_value,
>> resource_tags.domain_id tag_domain_id,
>> resource_tags.account_id tag_account_id,
>> resource_tags.resource_id tag_resource_id,
>> resource_tags.resource_uuid tag_resource_uuid,
>> resource_tags.resource_type tag_resource_type,
>> resource_tags.customer tag_customer,
>> async_job.id job_id,
>> async_job.uuid job_uuid,
>> async_job.job_status job_status,
>> async_job.account_id job_account_id
>> from
>> `cloud`.`volumes`
>> inner join
>> `cloud`.`account` ON volumes.account_id = account.id
>> inner join
>> `cloud`.`domain` ON volumes.domain_id = domain.id
>> left join
>> `cloud`.`projects` ON projects.project_account_id = account.id
>> left join
>> `cloud`.`data_center` ON volumes.data_center_id = data_center.id
>> left join
>> `cloud`.`vm_instance` ON volumes

RE: [ANNOUNCE] Santhosh Edukulla as a committer...

[Suresh Sadhu]

Congrats, Santhosh !


On 30/06/14 9:55 pm, "Alex Huang"  wrote:

>Hi All,
>
>The Project Management Committee (PMC) for Apache CloudStack has asked 
>Santhosh Edukulla to become a committer and we are pleased to announce 
>that he has accepted.
>
>Being a committer allows many contributors to contribute more 
>autonomously. For developers, it makes it easier to submit changes and 
>eliminates the need to have contributions reviewed via the patch 
>submission process. Whether contributions are development-related or 
>otherwise, it is a recognition of a contributor's participation in the 
>project and commitment to the project and the Apache Way.
>
>Please join me in congratulating Santhosh!
>
>--Alex, on behalf of the CloudStack PMC

RE: [ANNOUNCE] Santhosh Edukulla as a committer...

[Shweta Agarwal]

Congrats Santosh !!

-Original Message-
From: Alex Huang [mailto:alex.hu...@citrix.com] 
Sent: Monday, June 30, 2014 9:55 PM
To: dev@cloudstack.apache.org
Subject: [ANNOUNCE] Santhosh Edukulla as a committer...

Hi All,

The Project Management Committee (PMC) for Apache CloudStack has asked Santhosh 
Edukulla to become a committer and we are pleased to announce that he has 
accepted.

Being a committer allows many contributors to contribute more autonomously. For 
developers, it makes it easier to submit changes and eliminates the need to 
have contributions reviewed via the patch submission process. Whether 
contributions are development-related or otherwise, it is a recognition of a 
contributor's participation in the project and commitment to the project and 
the Apache Way.

Please join me in congratulating Santhosh!

--Alex, on behalf of the CloudStack PMC

RE: [ANNOUNCE] Santhosh Edukulla as a committer...

[Damoder Reddy]

Congratulations Santosh..

Thanks & Regards
Damodar/

-Original Message-
From: Shweta Agarwal [mailto:shweta.agar...@citrix.com] 
Sent: Tuesday, July 1, 2014 9:56 AM
To: dev@cloudstack.apache.org
Subject: RE: [ANNOUNCE] Santhosh Edukulla as a committer...

Congrats Santosh !!

-Original Message-
From: Alex Huang [mailto:alex.hu...@citrix.com] 
Sent: Monday, June 30, 2014 9:55 PM
To: dev@cloudstack.apache.org
Subject: [ANNOUNCE] Santhosh Edukulla as a committer...

Hi All,

The Project Management Committee (PMC) for Apache CloudStack has asked Santhosh 
Edukulla to become a committer and we are pleased to announce that he has 
accepted.

Being a committer allows many contributors to contribute more autonomously. For 
developers, it makes it easier to submit changes and eliminates the need to 
have contributions reviewed via the patch submission process. Whether 
contributions are development-related or otherwise, it is a recognition of a 
contributor's participation in the project and commitment to the project and 
the Apache Way.

Please join me in congratulating Santhosh!

--Alex, on behalf of the CloudStack PMC

Re: [ACS4.5] Can't access volumes on storage tab in GUI

[Mike Tutkowski]

Actually, in looking at "git blame", it appears this view has never had
those two columns.

I think the intent, however, is that those two columns exist in the view.

I'm adding them in my sandbox and testing this out now.


On Mon, Jun 30, 2014 at 10:11 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> I looked into this a bit more.
>
> It appears that the "volume_view" no longer has the following two columns:
>
> vm_template.name template_name
> vm_template.display_text template_display_text
>
> The problem is that the Java class, VolumeJoinVO, still has reference to
> them (a variable for each one).
>
> I would just remove these variables; however, they are still in use as
> they are returned to clients as responses (at least we try to return them,
> but get an exception before being able to do so).
>
> If we really want to remove these two columns, that will mean breaking the
> API, which really should wait until a major release.
>
>
> On Mon, Jun 30, 2014 at 9:07 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> Thanks for the reply.
>>
>> The weird part is that this is the second time I've recreated the DB and
>> seen this issue.
>>
>> If I have time a bit later, I can see if the SQL in Git is wrong and
>> update it with what you provided.
>>
>> Thanks!
>>
>>
>> On Mon, Jun 30, 2014 at 5:47 AM, Bharat Kumar 
>> wrote:
>>
>>> Hi Mike,
>>>
>>> I think the volume_view did not get created properly for some reason. I
>>> think recreating the volume_view will fix the problem.
>>>
>>> below commas should fix the issue.
>>>
>>> DROP VIEW IF EXISTS `cloud`.`volume_view`;
>>> CREATE VIEW `cloud`.`volume_view` AS
>>> select
>>> volumes.id,
>>> volumes.uuid,
>>> volumes.name,
>>> volumes.device_id,
>>> volumes.volume_type,
>>> volumes.size,
>>> volumes.min_iops,
>>> volumes.max_iops,
>>> volumes.created,
>>> volumes.state,
>>> volumes.attached,
>>> volumes.removed,
>>> volumes.pod_id,
>>> volumes.display_volume,
>>> volumes.format,
>>> volumes.path,
>>> volumes.chain_info,
>>> account.id account_id,
>>> account.uuid account_uuid,
>>> account.account_name account_name,
>>> account.type account_type,
>>> domain.id domain_id,
>>> domain.uuid domain_uuid,
>>> domain.name domain_name,
>>> domain.path domain_path,
>>> projects.id project_id,
>>> projects.uuid project_uuid,
>>> projects.name project_name,
>>> data_center.id data_center_id,
>>> data_center.uuid data_center_uuid,
>>> data_center.name data_center_name,
>>> data_center.networktype data_center_type,
>>> vm_instance.id vm_id,
>>> vm_instance.uuid vm_uuid,
>>> vm_instance.name vm_name,
>>> vm_instance.state vm_state,
>>> vm_instance.vm_type,
>>> user_vm.display_name vm_display_name,
>>> volume_store_ref.size volume_store_size,
>>> volume_store_ref.download_pct,
>>> volume_store_ref.download_state,
>>> volume_store_ref.error_str,
>>> volume_store_ref.created created_on_store,
>>> disk_offering.id disk_offering_id,
>>> disk_offering.uuid disk_offering_uuid,
>>> disk_offering.name disk_offering_name,
>>> disk_offering.display_text disk_offering_display_text,
>>> disk_offering.use_local_storage,
>>> disk_offering.system_use,
>>> disk_offering.bytes_read_rate,
>>> disk_offering.bytes_write_rate,
>>> disk_offering.iops_read_rate,
>>> disk_offering.iops_write_rate,
>>> disk_offering.cache_mode,
>>> storage_pool.id pool_id,
>>> storage_pool.uuid pool_uuid,
>>> storage_pool.name pool_name,
>>> cluster.hypervisor_type,
>>> vm_template.id template_id,
>>> vm_template.uuid template_uuid,
>>> vm_template.extractable,
>>> vm_template.type template_type,
>>> vm_template.name template_name,
>>> vm_template.display_text template_display_text,
>>> iso.id iso_id,
>>> iso.uuid iso_uuid,
>>> iso.name iso_name,
>>> iso.display_text iso_display_text,
>>> resource_tags.id tag_id,
>>> resource_tags.uuid tag_uuid,
>>> resource_tags.key tag_key,
>>> resource_tags.value tag_value,
>>> resource_tags.domain_id tag_domain_id,
>>> resource_tags.account_id tag_account_id,
>>> resource_tags.resource_id tag_resource_id,
>>> resource_tags.resource_uuid tag_resource_uuid,
>>> resource_tags.resource_type tag_resource_type,
>>> resource_tags.customer tag_customer,
>>> async_job.id job_id,
>>> async_job.uuid job_uuid,
>>> async_job.job_status job_status,
>>> async_job.account_id job_account_id
>>> from
>>> `cloud`

Re: Review Request 19446: CLOUDSTACK-6191: Volume provisioning type option

[Mike Tutkowski]

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


It looks like we're missing two columns in volume_view:

+vm_template.name template_name,
+vm_template.display_text template_display_text,

I noticed this in the GUI when you go to the Storage tab to view the volumes 
(you get an error).

I plan to check in a fix soon.

- Mike Tutkowski


On April 9, 2014, 4:58 p.m., Yoshikazu Nojima wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19446/
> ---
> 
> (Updated April 9, 2014, 4:58 p.m.)
> 
> 
> Review request for cloudstack, Mike Tutkowski, Marcus Sorensen, and Wido den 
> Hollander.
> 
> 
> Bugs: CLOUDSTACK-6191
> https://issues.apache.org/jira/browse/CLOUDSTACK-6191
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> purpose:
> Thin provisioning of a volume saves consumption of a storage, and fat 
> provisioning minimizes IOPS performance overhead.
> This feature adds a disk offering parameter to provide users an option to 
> select how to provision volumes.
> Especially, qcow2 format is known that its performance can be improved by 
> deploying a volume as a sparse file.[1] This feature also supports sparse 
> provisioning.
> 
> 
> http://itscblog.tamu.edu/improve-disk-io-performance-in-kvm/#.232---preallocation
> 
> Scope:
> First, start with KVM+NFS installation.
> Leave rooms to support other hypervisors.
> 
> For more details please refer fs: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Volume+provisioning+type+option
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/offering/DiskOffering.java 4641b9a 
>   api/src/com/cloud/storage/Storage.java 8ab2463 
>   api/src/com/cloud/storage/Volume.java 304dbcf 
>   api/src/com/cloud/vm/DiskProfile.java 5fdacf2 
>   api/src/org/apache/cloudstack/api/ApiConstants.java c7d6da1 
>   
> api/src/org/apache/cloudstack/api/command/admin/offering/CreateDiskOfferingCmd.java
>  67c9792 
>   
> api/src/org/apache/cloudstack/api/command/admin/offering/CreateServiceOfferingCmd.java
>  6cd5d84 
>   api/src/org/apache/cloudstack/api/response/DiskOfferingResponse.java 
> 91bd441 
>   api/src/org/apache/cloudstack/api/response/ServiceOfferingResponse.java 
> 764ade5 
>   api/src/org/apache/cloudstack/api/response/VolumeResponse.java 45c15da 
>   client/WEB-INF/classes/resources/messages.properties 8abe874 
>   core/src/org/apache/cloudstack/storage/to/VolumeObjectTO.java 11a3324 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  c5e0983 
>   engine/orchestration/test/com/cloud/vm/VirtualMachineManagerImplTest.java 
> 49b2fc5 
>   engine/schema/src/com/cloud/service/ServiceOfferingVO.java 3be0aaa 
>   engine/schema/src/com/cloud/storage/DiskOfferingVO.java 99214b2 
>   engine/schema/src/com/cloud/storage/VolumeVO.java 9f27c23 
>   
> engine/storage/volume/src/org/apache/cloudstack/storage/volume/VolumeObject.java
>  385f8e6 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  beb5e10 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtStorageVolumeDef.java
>  35777cf 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/IscsiAdmStorageAdaptor.java
>  761bb37 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/IscsiAdmStoragePool.java
>  2cecfa3 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStoragePool.java
>  ca3d32f 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStoragePoolManager.java
>  583d48a 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStorageProcessor.java
>  604bdae 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java
>  61d90e9 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStoragePool.java
>  605d154 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/StorageAdaptor.java
>  c751aab 
>   plugins/hypervisors/kvm/src/org/apache/cloudstack/utils/qemu/QemuImg.java 
> 4bec375 
>   
> plugins/hypervisors/kvm/test/org/apache/cloudstack/utils/qemu/QemuImgTest.java
>  8bdff4d 
>   
> plugins/network-elements/elastic-loadbalancer/src/com/cloud/network/lb/ElasticLoadBalancerManagerImpl.java
>  2a7bcac 
>   
> plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManagerImpl.java
>  89707c9 
>   
> plugins/network-elements/internal-loadbalancer/test/org/apache/cloudstack/internallbvmmgr/InternalLBVMManagerTest.java
>  f418586 
>   
> plugins/network-elements/internal-loadbalancer/test/org/apache/cloudstack/internal

Re: [ANNOUNCE] Santhosh Edukulla as a committer...

[Rajani Karuturi]

Congratulations Santhosh… 

~Rajani



On 01-Jul-2014, at 9:56 am, Shweta Agarwal  wrote:

> Congrats Santosh !!
> 
> -Original Message-
> From: Alex Huang [mailto:alex.hu...@citrix.com] 
> Sent: Monday, June 30, 2014 9:55 PM
> To: dev@cloudstack.apache.org
> Subject: [ANNOUNCE] Santhosh Edukulla as a committer...
> 
> Hi All,
> 
> The Project Management Committee (PMC) for Apache CloudStack has asked 
> Santhosh Edukulla to become a committer and we are pleased to announce that 
> he has accepted.
> 
> Being a committer allows many contributors to contribute more autonomously. 
> For developers, it makes it easier to submit changes and eliminates the need 
> to have contributions reviewed via the patch submission process. Whether 
> contributions are development-related or otherwise, it is a recognition of a 
> contributor's participation in the project and commitment to the project and 
> the Apache Way.
> 
> Please join me in congratulating Santhosh!
> 
> --Alex, on behalf of the CloudStack PMC

RE: [ANNOUNCE] Santhosh Edukulla as a committer...

[Devdeep Singh]

Congrats Santhosh.

> -Original Message-
> From: Alex Huang [mailto:alex.hu...@citrix.com]
> Sent: Monday, June 30, 2014 9:55 PM
> To: dev@cloudstack.apache.org
> Subject: [ANNOUNCE] Santhosh Edukulla as a committer...
> 
> Hi All,
> 
> The Project Management Committee (PMC) for Apache CloudStack has
> asked Santhosh Edukulla to become a committer and we are pleased to
> announce that he has accepted.
> 
> Being a committer allows many contributors to contribute more
> autonomously. For developers, it makes it easier to submit changes and
> eliminates the need to have contributions reviewed via the patch submission
> process. Whether contributions are development-related or otherwise, it is a
> recognition of a contributor's participation in the project and commitment to
> the project and the Apache Way.
> 
> Please join me in congratulating Santhosh!
> 
> --Alex, on behalf of the CloudStack PMC

RE: [ANNOUNCE] Santhosh Edukulla as a committer...

[Saksham Srivastava]

Congrats Santhosh.

-Original Message-
From: Alex Huang [mailto:alex.hu...@citrix.com] 
Sent: Monday, June 30, 2014 9:55 PM
To: dev@cloudstack.apache.org
Subject: [ANNOUNCE] Santhosh Edukulla as a committer...

Hi All,

The Project Management Committee (PMC) for Apache CloudStack has asked Santhosh 
Edukulla to become a committer and we are pleased to announce that he has 
accepted.

Being a committer allows many contributors to contribute more autonomously. For 
developers, it makes it easier to submit changes and eliminates the need to 
have contributions reviewed via the patch submission process. Whether 
contributions are development-related or otherwise, it is a recognition of a 
contributor's participation in the project and commitment to the project and 
the Apache Way.

Please join me in congratulating Santhosh!

--Alex, on behalf of the CloudStack PMC

Re: Review Request 22721: removed hard coded jdk_dirs in cloud-usage script

[Rajani Karuturi]

> On June 30, 2014, 8:29 p.m., Sebastien Goasguen wrote:
> > Seems I can take that to 4.3.1 as well ?

yes. this can be applied to 4.3.1 as well. let me know if it doesnt apply 
cleanly on 4.3.1. 


- Rajani


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


On June 18, 2014, 10:15 a.m., Rajani Karuturi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22721/
> ---
> 
> (Updated June 18, 2014, 10:15 a.m.)
> 
> 
> Review request for cloudstack, Kishan Kavala and Rayees Namathponnan.
> 
> 
> Bugs: CLOUDSTACK-6926
> https://issues.apache.org/jira/browse/CLOUDSTACK-6926
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> used to readlink -e and dirname to get the JAVA_HOME
> if JAVA_HOME is not already defined, sets it to jdk home if javac is present 
> else jre home if java is present.
> if nothing is present, it exits with error
> 
> 
> Diffs
> -
> 
>   packaging/centos63/cloud-usage.rc 6170379 
>   packaging/debian/init/cloud-usage 1cc75cc 
> 
> Diff: https://reviews.apache.org/r/22721/diff/
> 
> 
> Testing
> ---
> 
> 
> tested it when java is not installed, jre is installed, jdk installed or when 
> a older version is installed on centos 6.4 and ubuntu 14.04 
> 
> 
> Thanks,
> 
> Rajani Karuturi
> 
>

Re: [ACS4.5] Can't access volumes on storage tab in GUI

[Mike Tutkowski]

Upon further consideration, I forgot that we drop and re-create views in
the SQL - if need be - from release to release.

It looks like a new version of the volume_view went into 4.5 with
11f5bdd78de4121331b07995800f6e9e7c22f2c0, which is from Review Request
19446.

It appears volume_view is missing several columns.


On Mon, Jun 30, 2014 at 10:30 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Actually, in looking at "git blame", it appears this view has never had
> those two columns.
>
> I think the intent, however, is that those two columns exist in the view.
>
> I'm adding them in my sandbox and testing this out now.
>
>
> On Mon, Jun 30, 2014 at 10:11 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> I looked into this a bit more.
>>
>> It appears that the "volume_view" no longer has the following two columns:
>>
>> vm_template.name template_name
>> vm_template.display_text template_display_text
>>
>> The problem is that the Java class, VolumeJoinVO, still has reference to
>> them (a variable for each one).
>>
>> I would just remove these variables; however, they are still in use as
>> they are returned to clients as responses (at least we try to return them,
>> but get an exception before being able to do so).
>>
>> If we really want to remove these two columns, that will mean breaking
>> the API, which really should wait until a major release.
>>
>>
>> On Mon, Jun 30, 2014 at 9:07 AM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>>> Thanks for the reply.
>>>
>>> The weird part is that this is the second time I've recreated the DB and
>>> seen this issue.
>>>
>>> If I have time a bit later, I can see if the SQL in Git is wrong and
>>> update it with what you provided.
>>>
>>> Thanks!
>>>
>>>
>>> On Mon, Jun 30, 2014 at 5:47 AM, Bharat Kumar 
>>> wrote:
>>>
 Hi Mike,

 I think the volume_view did not get created properly for some reason. I
 think recreating the volume_view will fix the problem.

 below commas should fix the issue.

 DROP VIEW IF EXISTS `cloud`.`volume_view`;
 CREATE VIEW `cloud`.`volume_view` AS
 select
 volumes.id,
 volumes.uuid,
 volumes.name,
 volumes.device_id,
 volumes.volume_type,
 volumes.size,
 volumes.min_iops,
 volumes.max_iops,
 volumes.created,
 volumes.state,
 volumes.attached,
 volumes.removed,
 volumes.pod_id,
 volumes.display_volume,
 volumes.format,
 volumes.path,
 volumes.chain_info,
 account.id account_id,
 account.uuid account_uuid,
 account.account_name account_name,
 account.type account_type,
 domain.id domain_id,
 domain.uuid domain_uuid,
 domain.name domain_name,
 domain.path domain_path,
 projects.id project_id,
 projects.uuid project_uuid,
 projects.name project_name,
 data_center.id data_center_id,
 data_center.uuid data_center_uuid,
 data_center.name data_center_name,
 data_center.networktype data_center_type,
 vm_instance.id vm_id,
 vm_instance.uuid vm_uuid,
 vm_instance.name vm_name,
 vm_instance.state vm_state,
 vm_instance.vm_type,
 user_vm.display_name vm_display_name,
 volume_store_ref.size volume_store_size,
 volume_store_ref.download_pct,
 volume_store_ref.download_state,
 volume_store_ref.error_str,
 volume_store_ref.created created_on_store,
 disk_offering.id disk_offering_id,
 disk_offering.uuid disk_offering_uuid,
 disk_offering.name disk_offering_name,
 disk_offering.display_text disk_offering_display_text,
 disk_offering.use_local_storage,
 disk_offering.system_use,
 disk_offering.bytes_read_rate,
 disk_offering.bytes_write_rate,
 disk_offering.iops_read_rate,
 disk_offering.iops_write_rate,
 disk_offering.cache_mode,
 storage_pool.id pool_id,
 storage_pool.uuid pool_uuid,
 storage_pool.name pool_name,
 cluster.hypervisor_type,
 vm_template.id template_id,
 vm_template.uuid template_uuid,
 vm_template.extractable,
 vm_template.type template_type,
 vm_template.name template_name,
 vm_template.display_text template_display_text,
 iso.id iso_id,
 iso.uuid iso_uuid,
 iso.name iso_name,
 iso.display_text iso_display_text,
 resource_tags.id tag_id,
 resource_tags.uuid tag_uuid,
 resource_tags.key tag_key,
 resource_

Re: Review Request 19446: CLOUDSTACK-6191: Volume provisioning type option

[Mike Tutkowski]

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


Hi Noji,

Is it possible for you to take a look at this issue?

If you click on the Storage tab in the GUI when you should have one or more 
volumes, you'll see an error displayed.

It appears we're missing several columns in the volume_view.

I would recommend going back to previous SQL scripts to find the last time we 
drop and re-create volume_view and use that volume_view as a starting point for 
your new volume_view. You can then add on the additional columns that are 
necessary for your use case.

Does that sounds good? I could log a JIRA ticket for you, if that would help?

Thanks!
Mike

- Mike Tutkowski


On April 9, 2014, 4:58 p.m., Yoshikazu Nojima wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19446/
> ---
> 
> (Updated April 9, 2014, 4:58 p.m.)
> 
> 
> Review request for cloudstack, Mike Tutkowski, Marcus Sorensen, and Wido den 
> Hollander.
> 
> 
> Bugs: CLOUDSTACK-6191
> https://issues.apache.org/jira/browse/CLOUDSTACK-6191
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> purpose:
> Thin provisioning of a volume saves consumption of a storage, and fat 
> provisioning minimizes IOPS performance overhead.
> This feature adds a disk offering parameter to provide users an option to 
> select how to provision volumes.
> Especially, qcow2 format is known that its performance can be improved by 
> deploying a volume as a sparse file.[1] This feature also supports sparse 
> provisioning.
> 
> 
> http://itscblog.tamu.edu/improve-disk-io-performance-in-kvm/#.232---preallocation
> 
> Scope:
> First, start with KVM+NFS installation.
> Leave rooms to support other hypervisors.
> 
> For more details please refer fs: 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Volume+provisioning+type+option
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/offering/DiskOffering.java 4641b9a 
>   api/src/com/cloud/storage/Storage.java 8ab2463 
>   api/src/com/cloud/storage/Volume.java 304dbcf 
>   api/src/com/cloud/vm/DiskProfile.java 5fdacf2 
>   api/src/org/apache/cloudstack/api/ApiConstants.java c7d6da1 
>   
> api/src/org/apache/cloudstack/api/command/admin/offering/CreateDiskOfferingCmd.java
>  67c9792 
>   
> api/src/org/apache/cloudstack/api/command/admin/offering/CreateServiceOfferingCmd.java
>  6cd5d84 
>   api/src/org/apache/cloudstack/api/response/DiskOfferingResponse.java 
> 91bd441 
>   api/src/org/apache/cloudstack/api/response/ServiceOfferingResponse.java 
> 764ade5 
>   api/src/org/apache/cloudstack/api/response/VolumeResponse.java 45c15da 
>   client/WEB-INF/classes/resources/messages.properties 8abe874 
>   core/src/org/apache/cloudstack/storage/to/VolumeObjectTO.java 11a3324 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  c5e0983 
>   engine/orchestration/test/com/cloud/vm/VirtualMachineManagerImplTest.java 
> 49b2fc5 
>   engine/schema/src/com/cloud/service/ServiceOfferingVO.java 3be0aaa 
>   engine/schema/src/com/cloud/storage/DiskOfferingVO.java 99214b2 
>   engine/schema/src/com/cloud/storage/VolumeVO.java 9f27c23 
>   
> engine/storage/volume/src/org/apache/cloudstack/storage/volume/VolumeObject.java
>  385f8e6 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  beb5e10 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtStorageVolumeDef.java
>  35777cf 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/IscsiAdmStorageAdaptor.java
>  761bb37 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/IscsiAdmStoragePool.java
>  2cecfa3 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStoragePool.java
>  ca3d32f 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStoragePoolManager.java
>  583d48a 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStorageProcessor.java
>  604bdae 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java
>  61d90e9 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStoragePool.java
>  605d154 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/StorageAdaptor.java
>  c751aab 
>   plugins/hypervisors/kvm/src/org/apache/cloudstack/utils/qemu/QemuImg.java 
> 4bec375 
>   
> plugins/hypervisors/kvm/test/org/apache/cloudstack/utils/qemu/QemuImgTest.java
>  8bdff4d 
>   
> plugins/network-elements/elastic-loadbalancer/src/com/cloud/network/lb/ElasticLoadBalancerManagerImpl.java
>  2a7bcac 
>   
> plugins/network-elements/internal-loadbalancer/

Review Request 23192: Adding Readme and run checkbox at the end of the installation. Also installing mysql connector

[Damodar Reddy Talakanti]

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

Review request for cloudstack, Abhinandan Prateek and Koushik Das.


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

https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/CLOUDSTACK-6834


Repository: cloudstack-git


Description
---

Incorporated some feed back items.


Diffs
-

  client/pom.xml 29fef4f 
  scripts/installer/windows/ExitDialog.wxs PRE-CREATION 
  scripts/installer/windows/WixInstallerDialog.wxs 0282d8a 
  scripts/installer/windows/acs.wxs bf09afc 
  scripts/installer/windows/dependencies.wxs 987c561 
  scripts/installer/windows/en-us.wxl 2f34575 
  scripts/installer/windows/optionstheme_en-us.wxl c822929 
  scripts/installer/windows/readme.txt PRE-CREATION 

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


Testing
---

Tested on Windows 2012 Server


Thanks,

Damodar Reddy Talakanti

Review Request 23193: mark the test_01_primary_storage_iscsi as test that requires hardware

[bharat kumar]

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

Review request for cloudstack and Abhinandan Prateek.


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


Repository: cloudstack-git


Description
---

The test_01_primary_storage_iscsi is failing on simulator runs. It is because 
simulator cannot handle ISCSi type of storage. so we need to tag this test as a 
required hardware test.


Diffs
-

  test/integration/smoke/test_primary_storage.py 0312ad6 

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


Testing
---


Thanks,

bharat kumar