Re: Review Request 16540: CLOUDSTACK-5692: cleanup API response for primary/secondary storages

[ASF Subversion and Git Services]

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


Commit 330571cea64006e2bab0a19528290cce699107e5 in branch refs/heads/4.3 from 
Saksham Srivastava
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=330571c ]

CLOUDSTACK-5692: obscure passwords when using cifs as storage


- ASF Subversion and Git Services


On Jan. 16, 2014, 1:52 p.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16540/
> ---
> 
> (Updated Jan. 16, 2014, 1:52 p.m.)
> 
> 
> Review request for cloudstack and Devdeep Singh.
> 
> 
> Bugs: CLOUDSTACK-5692
> https://issues.apache.org/jira/browse/CLOUDSTACK-5692
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Cleanup the API response while listing primary/secondary stores while using 
> cifs.
> Cleanup logs and remove passwords.
> 
> 
> Diffs
> -
> 
>   core/src/com/cloud/agent/transport/Request.java cbeb112 
>   
> plugins/hypervisors/hyperv/src/com/cloud/hypervisor/hyperv/resource/HypervDirectConnectResource.java
>  1edfea3 
>   server/src/com/cloud/api/query/dao/ImageStoreJoinDaoImpl.java 8022871 
>   server/src/com/cloud/api/query/dao/StoragePoolJoinDaoImpl.java 4d2aac2 
> 
> Diff: https://reviews.apache.org/r/16540/diff/
> 
> 
> Testing
> ---
> 
> Tested locally.
> 
> The api response for list doesnot contain passwords:
> 
> "listimagestoresresponse" : { "count":1 ,"imagestore" : [  
> {"id":"182cfbfd-6343-4f35-804c-6b388fbf6a18","zoneid":"1ae705a4-c9bc-4977-9260-ce128d7fd3d8","zonename":"zone1","name":"secondary1","url":"cifs://10.102.192.151/SMB-Share/saksham/secondary?user=administrator&domain=blr","protocol":"cifs","providername":"NFS","scope":"ZONE","details":[]}
>  ] } }
> 
> The logs also do not contain passwords :
> 
> 2014-01-16 18:48:53,288 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Job-Executor-2:ctx-24ee5b9d ctx-b4e28b06) Complete async job-62, jobStatus: 
> SUCCEEDED, resultCode: 0, result: 
> org.apache.cloudstack.api.response.StoragePoolResponse/storagepool/{"id":"c59cc1c9-8d16-3090-95e7-d5c54839cf2c","zoneid":"1ae705a4-c9bc-4977-9260-ce128d7fd3d8","zonename":"zone1","podid":"bd328cfc-692e-4c8c-8d32-e2a34abaaa37","podname":"pod1","name":"primary1","ipaddress":"10.102.192.150","path":"/SMB-Share/saksham/primary?user\u003dadministrator\u0026domain\u003dblr","created":"2014-01-07T16:28:35+0530","type":"NetworkFilesystem","clusterid":"fc1df888-0e90-45c2-8555-5d4ed61c7bc3","clustername":"cluster1","disksizetotal":500105736192,"disksizeallocated":0,"tags":"sggss","state":"Up","scope":"CLUSTER","jobid":"dfbd2072-48dc-457d-a417-312a74c517f9","jobstatus":0}
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

Re: Review Request 16540: CLOUDSTACK-5692: cleanup API response for primary/secondary storages

[Devdeep Singh]

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

Ship it!


Ship It!

- Devdeep Singh


On Jan. 16, 2014, 1:52 p.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16540/
> ---
> 
> (Updated Jan. 16, 2014, 1:52 p.m.)
> 
> 
> Review request for cloudstack and Devdeep Singh.
> 
> 
> Bugs: CLOUDSTACK-5692
> https://issues.apache.org/jira/browse/CLOUDSTACK-5692
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Cleanup the API response while listing primary/secondary stores while using 
> cifs.
> Cleanup logs and remove passwords.
> 
> 
> Diffs
> -
> 
>   core/src/com/cloud/agent/transport/Request.java cbeb112 
>   
> plugins/hypervisors/hyperv/src/com/cloud/hypervisor/hyperv/resource/HypervDirectConnectResource.java
>  1edfea3 
>   server/src/com/cloud/api/query/dao/ImageStoreJoinDaoImpl.java 8022871 
>   server/src/com/cloud/api/query/dao/StoragePoolJoinDaoImpl.java 4d2aac2 
> 
> Diff: https://reviews.apache.org/r/16540/diff/
> 
> 
> Testing
> ---
> 
> Tested locally.
> 
> The api response for list doesnot contain passwords:
> 
> "listimagestoresresponse" : { "count":1 ,"imagestore" : [  
> {"id":"182cfbfd-6343-4f35-804c-6b388fbf6a18","zoneid":"1ae705a4-c9bc-4977-9260-ce128d7fd3d8","zonename":"zone1","name":"secondary1","url":"cifs://10.102.192.151/SMB-Share/saksham/secondary?user=administrator&domain=blr","protocol":"cifs","providername":"NFS","scope":"ZONE","details":[]}
>  ] } }
> 
> The logs also do not contain passwords :
> 
> 2014-01-16 18:48:53,288 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Job-Executor-2:ctx-24ee5b9d ctx-b4e28b06) Complete async job-62, jobStatus: 
> SUCCEEDED, resultCode: 0, result: 
> org.apache.cloudstack.api.response.StoragePoolResponse/storagepool/{"id":"c59cc1c9-8d16-3090-95e7-d5c54839cf2c","zoneid":"1ae705a4-c9bc-4977-9260-ce128d7fd3d8","zonename":"zone1","podid":"bd328cfc-692e-4c8c-8d32-e2a34abaaa37","podname":"pod1","name":"primary1","ipaddress":"10.102.192.150","path":"/SMB-Share/saksham/primary?user\u003dadministrator\u0026domain\u003dblr","created":"2014-01-07T16:28:35+0530","type":"NetworkFilesystem","clusterid":"fc1df888-0e90-45c2-8555-5d4ed61c7bc3","clustername":"cluster1","disksizetotal":500105736192,"disksizeallocated":0,"tags":"sggss","state":"Up","scope":"CLUSTER","jobid":"dfbd2072-48dc-457d-a417-312a74c517f9","jobstatus":0}
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

Re: Review Request 16540: CLOUDSTACK-5692: cleanup API response for primary/secondary storages

[ASF Subversion and Git Services]

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


Commit 06f8c1de7559f8e1d22ffe1ded3a089dc109f784 in branch refs/heads/master 
from Saksham Srivastava
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=06f8c1d ]

CLOUDSTACK-5692: obscure passwords when using cifs as storage


- ASF Subversion and Git Services


On Jan. 16, 2014, 1:52 p.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16540/
> ---
> 
> (Updated Jan. 16, 2014, 1:52 p.m.)
> 
> 
> Review request for cloudstack and Devdeep Singh.
> 
> 
> Bugs: CLOUDSTACK-5692
> https://issues.apache.org/jira/browse/CLOUDSTACK-5692
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Cleanup the API response while listing primary/secondary stores while using 
> cifs.
> Cleanup logs and remove passwords.
> 
> 
> Diffs
> -
> 
>   core/src/com/cloud/agent/transport/Request.java cbeb112 
>   
> plugins/hypervisors/hyperv/src/com/cloud/hypervisor/hyperv/resource/HypervDirectConnectResource.java
>  1edfea3 
>   server/src/com/cloud/api/query/dao/ImageStoreJoinDaoImpl.java 8022871 
>   server/src/com/cloud/api/query/dao/StoragePoolJoinDaoImpl.java 4d2aac2 
> 
> Diff: https://reviews.apache.org/r/16540/diff/
> 
> 
> Testing
> ---
> 
> Tested locally.
> 
> The api response for list doesnot contain passwords:
> 
> "listimagestoresresponse" : { "count":1 ,"imagestore" : [  
> {"id":"182cfbfd-6343-4f35-804c-6b388fbf6a18","zoneid":"1ae705a4-c9bc-4977-9260-ce128d7fd3d8","zonename":"zone1","name":"secondary1","url":"cifs://10.102.192.151/SMB-Share/saksham/secondary?user=administrator&domain=blr","protocol":"cifs","providername":"NFS","scope":"ZONE","details":[]}
>  ] } }
> 
> The logs also do not contain passwords :
> 
> 2014-01-16 18:48:53,288 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (Job-Executor-2:ctx-24ee5b9d ctx-b4e28b06) Complete async job-62, jobStatus: 
> SUCCEEDED, resultCode: 0, result: 
> org.apache.cloudstack.api.response.StoragePoolResponse/storagepool/{"id":"c59cc1c9-8d16-3090-95e7-d5c54839cf2c","zoneid":"1ae705a4-c9bc-4977-9260-ce128d7fd3d8","zonename":"zone1","podid":"bd328cfc-692e-4c8c-8d32-e2a34abaaa37","podname":"pod1","name":"primary1","ipaddress":"10.102.192.150","path":"/SMB-Share/saksham/primary?user\u003dadministrator\u0026domain\u003dblr","created":"2014-01-07T16:28:35+0530","type":"NetworkFilesystem","clusterid":"fc1df888-0e90-45c2-8555-5d4ed61c7bc3","clustername":"cluster1","disksizetotal":500105736192,"disksizeallocated":0,"tags":"sggss","state":"Up","scope":"CLUSTER","jobid":"dfbd2072-48dc-457d-a417-312a74c517f9","jobstatus":0}
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

RE: Change SCSI type in VMware

[Sateesh Chodapuneedi]

Sean, 

I have picked up this task, CLOUDSTACK-4787.
By early next week, I will comeup with proposal to support subtypes of scsi 
disk controllers in CloudStack for vSphere.

>Is there a workaround for this issue?
I think yes. Try changing the controller type to Lsi Logic SAS and start the VM 
to continue the installation from ISO.
Please let me know how it goes.

Regards,
Sateesh

> -Original Message-
> From: Sean Hamilton [mailto:s...@seanhamilton.co.uk]
> Sent: 16 January 2014 22:58
> To: us...@cloudstack.apache.org
> Subject: Re: Change SCSI type in VMware
> 
> Thanks!
> 
> 
> On 16 January 2014 09:03, sebgoa  wrote:
> 
> >
> > On Jan 15, 2014, at 11:01 AM, Sean Hamilton 
> > wrote:
> >
> > > It's out of my league too. Hope this comes in a release soon.
> > >
> >
> > I change the ticket to a 'Bug' and added 4.3 has a branch where the
> > problem exists.
> > It should give it some visibility in JIRA.
> >
> > Hopefully a fix soon
> >
> > -sebastien
> >
> > >
> > > On 9 January 2014 11:26, Erik Weber  wrote:
> > >
> > >> On Thu, Jan 9, 2014 at 12:07 PM, Sean Hamilton
> > >>  > >>> wrote:
> > >>
> > >>> Hi Guys,
> > >>>
> > >>> One of our users is trying to use Windows Server 2012 R2.
> > >>> On install they can't see the disk attached. I checked and it
> > >>> looks
> > like
> > >>> Microsoft removed the LSI Logic Parallel driver from that OS.
> > >>> Changing
> > >> the
> > >>> storage adapter to LSI Logic SAS should work (and does work in VMware).
> > >> In
> > >>> CloudStack there is no option for this. I see a feature open for it:
> > >>> https://issues.apache.org/jira/browse/CLOUDSTACK-4787
> > >>>
> > >>> Does anyone have a workaround? Even if I change the value in
> > >>> VMware,
> > when
> > >>> CloudStack powers the instance on, it changes back to Parallel.
> > >>>
> > >>> I'd really like to offer support for the latest Operating Systems
> > >>> in CloudStack and was wondering if anyone else was hit by the same 
> > >>> issue?
> > >>>
> > >>>
> > >>
> > >> I haven't been able to find a workaround yet.
> > >> I did take a look in eclipse and noticed that the vmware jars do
> > >> have
> > the
> > >> appropriate setting for it, it's just a matter of adding it to the
> > >> cloudstack ui, storing and using it.
> > >>
> > >> However, that's out of my league.
> > >>
> > >>
> > >> --
> > >> Erik
> > >>
> >
> >

Build failed in Jenkins: build-master #76

[jenkins]

See 

Changes:

[Devdeep Singh] CLOUDSTACK-5692: obscure passwords when using cifs as storage

--
[...truncated 3710 lines...]
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-plugin-storage-volume-solidfire ---
[INFO] Compiling 4 source files to 

[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ 
cloud-plugin-storage-volume-solidfire ---
[INFO] Tests are skipped.
[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Plugin - Storage Volume default provider 
4.4.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ 
cloud-plugin-storage-volume-default ---
[INFO] Deleting 

 (includes = [**/*], excludes = [])
[INFO] Deleting 

 (includes = [target, dist], excludes = [])
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-plugin-storage-volume-default ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-plugin-storage-volume-default ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-plugin-storage-volume-default ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
cloud-plugin-storage-volume-default ---
[INFO] Compiling 3 source files to 

[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-plugin-storage-volume-default ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-plugin-storage-volume-default ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ 
cloud-plugin-storage-volume-default ---
[INFO] Tests are skipped.
[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Plugin - Storage Volume sample provider 
4.4.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ 
cloud-plugin-storage-volume-sample ---
[INFO] Deleting 

 (includes = [**/*], excludes = [])
[INFO] Deleting 

 (includes = [target, dist], excludes = [])
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ 
cloud-plugin-storage-volume-sample ---
[INFO] Starting audit...
Audit done.

[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ 
cloud-plugin-storage-volume-sample ---
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-plugin-storage-volume-sample ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
cloud-plugin-storage-volume-sample ---
[INFO] Compiling 3 source files to 

[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-plugin-storage-volume-sample ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-plugin-storage-volume-sample ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-

Re: [jira] [Commented] (CLOUDSTACK-5834) [upgrade]Error while collecting disk stats from : You gave an invalid object reference. The object may have recently been deleted

[Wei ZHOU]

Can you remove the xapi*.jar and upload xapi-5.6.100-1-SNAPSHOT.jar
in deps/XenServerJava/target/ directory to  /usr/share/cloudstack-
management/webapps/client/WEB-INF/lib/ ?



2014/1/17 Vincent Vuong (JIRA) 

>
> [
> https://issues.apache.org/jira/browse/CLOUDSTACK-5834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13874600#comment-13874600]
>
> Vincent Vuong commented on CLOUDSTACK-5834:
> ---
>
> management server:
>
>
> /usr/share/cloudstack-management/webapps/client/WEB-INF/lib/xapi-5.6.100-1-20130125.183249-474.jar
>
> where is the xapi-*.jar located on the host?  xenserver hosts were never
> upgraded, only the management server.
>
> > [upgrade]Error while collecting disk stats from : You gave an invalid
> object reference.  The object may have recently been deleted
> >
> --
> >
> > Key: CLOUDSTACK-5834
> > URL:
> https://issues.apache.org/jira/browse/CLOUDSTACK-5834
> > Project: CloudStack
> >  Issue Type: Bug
> >  Security Level: Public(Anyone can view this level - this is the
> default.)
> >  Components: Management Server, XenServer
> >Affects Versions: 4.3.0
> >Reporter: prashant kumar mishra
> >Assignee: Anthony Xu
> > Fix For: 4.3.0
> >
> > Attachments: MS_XEN_log_DB.rar
> >
> >
> > Steps
> > ==
> > 1-prepare ACS 4.2 setup with xen6.2 host
> > 2-upgrade CS to 4.3 and upgrade xen 6.2 to xen6.2sp1
> > After upgrade i am seeing error message in log whenever VmStatsCollector
> is running.
> > Logs
> > ==
> > 2014-01-08 13:15:08,182 DEBUG [c.c.s.StatsCollector]
> (StatsCollector-2:ctx-aa75b506) VmStatsCollector is running...
> > 2014-01-08 13:15:08,207 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-141:ctx-74d0d04a) Seq 1-498139202: Executing request
> > 2014-01-08 13:15:08,358 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-141:ctx-74d0d04a) Vm cpu utilization 0.0
> > 2014-01-08 13:15:08,359 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-141:ctx-74d0d04a) Vm cpu utilization 0.00453125
> > 2014-01-08 13:15:08,369 WARN  [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-141:ctx-74d0d04a) Error while collecting disk stats from :
> > You gave an invalid object reference.  The object may have recently been
> deleted.  The class parameter gives the type of reference given, and the
> handle parameter echoes the bad value given.
> > at com.xensource.xenapi.Types.checkResponse(Types.java:209)
> > at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
> > at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909)
> > at
> com.xensource.xenapi.VBDMetrics.getIoReadKbs(VBDMetrics.java:210)
> > at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.getVmStats(CitrixResourceBase.java:2784)
> > at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:2684)
> > at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:493)
> > at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
> > at
> com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
> > at
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
> > 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
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> > at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> > at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> > at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> > at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> > at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> > at java.lang.Thread.run

RE: Hyper-V

[Devdeep Singh]

Hi Paul,

Did you get a chance to try it in Advanced mode? Did it work for you? Anshul 
recently made a change to secure the communication between the management 
server and the agent. If you try with the latest changes you'll have to install 
a certificate so that the management server can talk to the agent. Following 
link [1] will tell you how to go about it.

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Manually+Creating+and+installing+self+signed+certificate+for+CloudStack+Management+Server+communication+with+Hyper-V+agent

Regards,
Devdeep

-Original Message-
From: Devdeep Singh [mailto:devdeep.si...@citrix.com] 
Sent: Thursday, January 16, 2014 7:05 PM
To: dev@cloudstack.apache.org
Cc: Donal Lafferty; Rajesh Battala; Anshul Gangwar
Subject: RE: Hyper-V

Hi Paul,

>From the logs it looks like you have setup the zone in Basic mode. Basic mode 
>is right now not supported for Hyper-V. Can you set it up in Advanced mode and 
>see if it works?

Regards,
Devdeep

P.S. I just tried setting up the zone in Basic mode and confirmed I got the 
same exception.

-Original Message-
From: Paul Angus [mailto:paul.an...@shapeblue.com] 
Sent: Thursday, January 16, 2014 5:25 PM
To: dev@cloudstack.apache.org
Cc: Donal Lafferty; Rajesh Battala; Anshul Gangwar
Subject: RE: Hyper-V

I've got the System VMs creating, but not starting now...

Error seems to be:
POST response 
is[{"com.cloud.agent.api.StartAnswer":{"result":false,"details":"com.cloud.agent.api.StartCommand
 fail on exceptionObject reference not set to an instance of an object

Agent log:
http://pastebin.com/zhfXia9v

mgmt. log:
http://pastebin.com/ZUjBgqX8

Regards,

Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus 
paul.an...@shapeblue.com

-Original Message-
From: Devdeep Singh [mailto:devdeep.si...@citrix.com]
Sent: 15 January 2014 02:57
To: dev@cloudstack.apache.org
Cc: Donal Lafferty; Rajesh Battala; Anshul Gangwar
Subject: RE: Hyper-V

Hi Paul,

I have put in a fix for the issue with local storage that you reported earlier 
[1]. Please pull the latest changes and try. It should work now. I'll look into 
the error you are facing with shared and let you know once it is fixed.

[1] https://issues.apache.org/jira/browse/CLOUDSTACK-5869

Regards,
Devdeep

From: Paul Angus [mailto:paul.an...@shapeblue.com]
Sent: Tuesday, January 14, 2014 9:19 PM
To: dev@cloudstack.apache.org
Cc: Donal Lafferty; Rajesh Battala; Anshul Gangwar
Subject: Hyper-V

Guys,

Primary storage local or shared is still giving me grief.

See the error below from the agent log when trying to create a system VM. the 
final error is 'org.apache.cloudstack.storage.command.CopyCommand failed on 
exception, net use of share 10.0.1.27/hypervPri/storfailed with Error: 
Unknown, 1219",'
The share is \\10.0.1.27\hypervPri\stor in UNC notation.


2014-01-14 15:40:12,566 [6] INFO  HypervResource.HypervResourceController 
[cc482c9e-0d97-4be8-9dc8-2e546bdb00c1] - 
org.apache.cloudstack.storage.command.CopyCommand{
  "srcTO": {
"org.apache.cloudstack.storage.to.TemplateObjectTO": {
  "path": "template/tmpl/1/9/",
  "origUrl": 
"http://download.cloud.com/templates/4.3/systemvm64template-2013-12-23-hyperv.vhd.bz2";,
  "uuid": "18767718-7d1b-11e3-b742-0050568b4d4c",
  "id": 9,
  "format": "VHD",
  "accountId": 1,
  "checksum": "5df45ee6ebe1b703a8805f4e1f4d0818",
  "hvm": false,
  "displayText": "SystemVM Template (HyperV)",
  "imageDataStore": {
"com.cloud.agent.api.to.NfsTO": {
 "_url": 
"cifs://10.0.100.5/stor_Cloud/Secondary/ACS43?user=hyperv&password=hyperv&domain=angusnet",
  "_role": "Image"
}
  },
  "name": "routing-9",
  "hypervisorType": "Hyperv"
}
  },
  "destTO": {
"org.apache.cloudstack.storage.to.TemplateObjectTO": {
  "origUrl": 
"http://download.cloud.com/templates/4.3/systemvm64template-2013-12-23-hyperv.vhd.bz2";,
  "uuid": "18767718-7d1b-11e3-b742-0050568b4d4c",
  "id": 9,
  "format": "VHD",
  "accountId": 1,
  "checksum": "5df45ee6ebe1b703a8805f4e1f4d0818",
  "hvm": false,
  "displayText": "SystemVM Template (HyperV)",
  "imageDataStore": {
"org.apache.cloudstack.storage.to.PrimaryDataStoreTO": {
  "uuid": "2bcff176-e5f3-350e-936a-7ee19a0e8658",
  "id": 2,
  "poolType": "NetworkFilesystem",
  "host": "10.0.1.27",
  "path": 
"/hypervPri/stor?user=hyperv&password=hyperv13!&domain=angusnet.local",
  "port": 445,
  "url": 
"NetworkFilesystem://10.0.1.27//hypervPri/stor?user=hyperv&password=hyperv13!&domain=angusnet.local/?ROLE=Primary&STOREUUID=2bcff176-e5f3-350e-936a-7ee19a0e8658"
}
  },
  "name": "routing-9",
  "hypervisorType": "Hyperv"
}
  },
  "executeInSequence": false,
  "options": {},
  "contextMap": {},
  "wait": 10800
}
2014-01-14 15:40:12,581 [6] ERROR HypervResource.HypervResourceControl

Re: Review Request 13560: CLOUDSTACK-4021 : Update the test test_explicit_dedication.py according to new changes to dedicated resources

[Saksham Srivastava]

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

(Updated Jan. 17, 2014, 11:06 a.m.)


Review request for cloudstack, Devdeep Singh, Girish Shilamkar, Prachi Damle, 
and Rayees Namathponnan.


Changes
---

Resubmitting an old patch by removing merge conflicts.


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


Repository: cloudstack-git


Description
---

test_explicit_dedication.py need to modified according to the new changes to 
dedicate resources feature.
Now dedicate a host first and use the created affinity group to deploy vm.


Diffs (updated)
-

  test/integration/component/test_explicit_dedication.py 7aefc21 
  tools/marvin/marvin/integration/lib/common.py 550de1a 

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


Testing
---

test runs successfully whenever an empty host is found.


Thanks,

Saksham Srivastava

Hyper-V Issues

[Donal Lafferty]

Hi Paul,

Thanks for trying out the Hyper-V agent over the last couple of weeks!  I'm not 
always able to help you with the problems, so I've compiled a list of resources 
below to help with problems, collaboration and documentation.

For problems you see, there is a team in Bangalore dedicated to polishing up 
the Hyper-V agent.  They have been following up on the issues you've found.  
However, I've included the email of team lead, Devdeep Singh, in the CC if you 
want him to take a look at a specific JIRA issue you've created.

For collaborating to provide user guidance, there is a wiki at 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Hyper-V+Community+Tips+and+FAQ
   It's a good place to accumulate gotchas that you, myself and other users 
come across.  It's pretty empty at the moment, so make any additions or edits 
you want.

For documentation, there are Hyper-V sections in docs repo.  In 
https://git-wip-us.apache.org/repos/asf?p=cloudstack-docs.git;a=tree;f=en-US;h=5fdde1c7134b675e4ede9f13b01e937406adc92e;hb=e8359806e3bbb49292deedb5bca11dc7ab0c9b7a
 files matching "hyperv-" tend to be Hyper-V related; however, I think a JIRA 
issue with section name should point Radhika in the right direction for making 
a fix.

Look forward to seeing you at the CloudStack European User Group Meeting in 
London next Thursday,

DL

Jenkins build is back to normal : build-master #77

[jenkins]

See 

Re: cidrs in acls

[Daan Hoogland]

That was what I thought as well. What was the retionale to join them
into one field?

On Fri, Jan 17, 2014 at 8:32 AM, Kishan Kavala  wrote:
> Daan,
>   Similar to firewall_rules_cidrs, separate table can be used to store acl 
> cidrs. Maybe in network_acl_item_cidrs.
>
> Regards,
> kishan
>
>> -Original Message-
>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> Sent: Friday, 17 January 2014 1:05 AM
>> To: Kishan Kavala
>> Cc: dev
>> Subject: cidrs in acls
>>
>> H Kishan,
>>
>> I see you implemented CLOUDSTACK-763. it merges a lot of cidrs into one 
>> field.
>> The api doesn't check the field length. I enlarged the field in the create 
>> table
>> statement to 2048 for the 4.3 branch. Can you help me think about a more 
>> solid
>> solution, please. It seems to me those cidrs shouldn't be joint into one 
>> field.
>>
>> regards,
>> Daan

Re: IPv6 in VPC (was Re: IPv6 plan - questions)

[Daan Hoogland]

On Fri, Jan 17, 2014 at 8:45 AM, Marcus Sorensen  wrote:
> guest networks, my initial preference would be for SLAAC, but I think
> ultimately we'd want to be able to assign multiple ips to a guest.
> With the 64 bits of the SLAAC space dedicated to all of the unique MAC
> address possibilities, we can't really do that. We may want to
> consider DHCP with static assignments from the beginning.


Wouldn't an admin that requires this just have to assign bigger
networks? /60 for the tiers and /56 for the vpc... Seems like this is
not an argument against SLAAC in favor of DHCP. do tell me I am
stoned, Daan

Re: IPv6 in VPC (was Re: IPv6 plan - questions)

[Marcus Sorensen]

>From what I understand, SLAAC only works with /64s, larger breaks
various discovery protocols and is against RFC. Half of the address is
the prefix and the other half is (mostly) MAC. What you're describing
would work if we didn't want to do SLAAC, but would require an
alternate means of assignment.  This sort of goes back to me wanting
to be able to assign multiple ranges to a network, say a "SLAAC /64"
and a "Manually assigned /64" by providing a field to tag the prefix
with a type.

On Fri, Jan 17, 2014 at 6:43 AM, Daan Hoogland  wrote:
> On Fri, Jan 17, 2014 at 8:45 AM, Marcus Sorensen  wrote:
>> guest networks, my initial preference would be for SLAAC, but I think
>> ultimately we'd want to be able to assign multiple ips to a guest.
>> With the 64 bits of the SLAAC space dedicated to all of the unique MAC
>> address possibilities, we can't really do that. We may want to
>> consider DHCP with static assignments from the beginning.
>
>
> Wouldn't an admin that requires this just have to assign bigger
> networks? /60 for the tiers and /56 for the vpc... Seems like this is
> not an argument against SLAAC in favor of DHCP. do tell me I am
> stoned, Daan

Re: IPv6 in VPC (was Re: IPv6 plan - questions)

[Daan Hoogland]

Ok, I though those could come from the same vpc range.

On Fri, Jan 17, 2014 at 2:58 PM, Marcus Sorensen  wrote:
> From what I understand, SLAAC only works with /64s, larger breaks
> various discovery protocols and is against RFC. Half of the address is
> the prefix and the other half is (mostly) MAC. What you're describing
> would work if we didn't want to do SLAAC, but would require an
> alternate means of assignment.  This sort of goes back to me wanting
> to be able to assign multiple ranges to a network, say a "SLAAC /64"
> and a "Manually assigned /64" by providing a field to tag the prefix
> with a type.
>
> On Fri, Jan 17, 2014 at 6:43 AM, Daan Hoogland  
> wrote:
>> On Fri, Jan 17, 2014 at 8:45 AM, Marcus Sorensen  wrote:
>>> guest networks, my initial preference would be for SLAAC, but I think
>>> ultimately we'd want to be able to assign multiple ips to a guest.
>>> With the 64 bits of the SLAAC space dedicated to all of the unique MAC
>>> address possibilities, we can't really do that. We may want to
>>> consider DHCP with static assignments from the beginning.
>>
>>
>> Wouldn't an admin that requires this just have to assign bigger
>> networks? /60 for the tiers and /56 for the vpc... Seems like this is
>> not an argument against SLAAC in favor of DHCP. do tell me I am
>> stoned, Daan

Fwd: Issues after upgrading CS from 4.1 to 4.2.1 managing XenServer 6.0.2 clusters

[Pierre-Luc Dion]

Hi,

We've upgrade our Cloudstack environment from 4.1 to 4.2.1, it is currently
managing XenServer 6.0.2 clusters.

1. Since we have upgraded to 4.2.1 we noticed that Secondary Storage Name
have been rename and we now see UUID's of SS.
2. On one cluster that is using local-Storage and Shared Storage we have
removed on host from the XenServer Pool, since then,  this error keep
repeating in the management-server.log:

2014-01-16 17:01:17,898 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-437:null) Seq 1-590413869: Response Received:
2014-01-16 17:01:17,898 DEBUG [agent.transport.Request]
(StatsCollector-2:null) Seq 1-590413869: Received:  { Ans: , MgmtId:
152067623530867, via: 1, Ver: v1, Flags: 10, { GetVmStatsAnswer } }
2014-01-16 17:01:17,949 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-73:null) Seq 2-1599340596: Executing request
2014-01-16 17:01:18,191 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-320:null) Ping from 69
2014-01-16 17:01:18,369 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-73:null) Vm cpu utilization 0.0064062499
2014-01-16 17:01:18,369 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-73:null) Vm cpu utilization 12.9175
2014-01-16 17:01:18,369 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-73:null) Vm cpu utilization 24.08
2014-01-16 17:01:18,369 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-73:null) Vm cpu utilization 0.29504
2014-01-16 17:01:18,369 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-73:null) Vm cpu utilization 23.8075
2014-01-16 17:01:18,370 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-73:null) Vm cpu utilization 10.09875
2014-01-16 17:01:18,370 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-73:null) Vm cpu utilization 0.29828125
2014-01-16 17:01:18,370 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-73:null) Vm cpu utilization 2.6504
2014-01-16 17:01:18,370 DEBUG [xen.resource.CitrixResourceBase]
(DirectAgent-73:null) Vm cpu utilization 0.8375
2014-01-16 17:01:18,507 WARN  [xen.resource.CitrixResourceBase]
(DirectAgent-73:null) Error while collecting disk stats from :
You gave an invalid object reference.  The object may have recently been
deleted.  The class parameter gives the type of reference given, and the
handle parameter echoes the bad value given.
at com.xensource.xenapi.Types.checkResponse(Types.java:209)
at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
at
com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909)
at com.xensource.xenapi.VBDMetrics.getIoReadKbs(VBDMetrics.java:210)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.getVmStats(CitrixResourceBase.java:2791)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:2691)
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:497)
at
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
at
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:701)
2014-01-16 17:01:18,509 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-73:null) Seq 2-1599340596: Response Received:


Also, Because we were planning to upgrade the pool using Local-Storage we
start moving VM into another Primary Storage using regular procedure of
turning off Instances, and moving them as Admin account. this keep failing
but also delete Instance DISK which result of having data lost.

Now, we can't see our hosts list and System VM list from the Infrastructure
tab (see attachements), we only see ERROR.

here is the apilog.log when trying to show hosts:

2014-01-16 17:13:35,337 INFO  [cloud.api.ApiServer] (catalina-exec-18:null)
(userId=2 accountId=2 sessionId=4F907F8E77BE76ADF46BB4FBE6B23BC0)
172.24.0.20 -- GET
command=listHosts&response=json&sessionkey=tPdf1uSuogiM1ubmRFuPuFV%2FLzM%3D&page=1&pageSize=20&type=routing&listAll=true&_=1389910415201
530 null

is their any other logs to look at to understands what's broken because the
upper stacktrace is clueless for me and their is no errors in the
management-server.log when trying to display hosts.

Regards,

Pierre-Luc Dion
Architecte de Solution Cloud | Cloud Solutions Architect
514-447-3456, 1101
- - -

*CloudOps*420 rue Guy
Montréa

Re: Issues after upgrading CS from 4.1 to 4.2.1 managing XenServer 6.0.2 clusters

[Wei ZHOU]

same issue: CLOUDSTACK-5834


2014/1/17 Pierre-Luc Dion 

> Hi,
>
> We've upgrade our Cloudstack environment from 4.1 to 4.2.1, it is
> currently managing XenServer 6.0.2 clusters.
>
> 1. Since we have upgraded to 4.2.1 we noticed that Secondary Storage Name
> have been rename and we now see UUID's of SS.
> 2. On one cluster that is using local-Storage and Shared Storage we have
> removed on host from the XenServer Pool, since then,  this error keep
> repeating in the management-server.log:
>
> 2014-01-16 17:01:17,898 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-437:null) Seq 1-590413869: Response Received:
> 2014-01-16 17:01:17,898 DEBUG [agent.transport.Request]
> (StatsCollector-2:null) Seq 1-590413869: Received:  { Ans: , MgmtId:
> 152067623530867, via: 1, Ver: v1, Flags: 10, { GetVmStatsAnswer } }
> 2014-01-16 17:01:17,949 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-73:null) Seq 2-1599340596: Executing request
> 2014-01-16 17:01:18,191 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-320:null) Ping from 69
> 2014-01-16 17:01:18,369 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-73:null) Vm cpu utilization 0.0064062499
> 2014-01-16 17:01:18,369 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-73:null) Vm cpu utilization 12.9175
> 2014-01-16 17:01:18,369 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-73:null) Vm cpu utilization 24.08
> 2014-01-16 17:01:18,369 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-73:null) Vm cpu utilization 0.29504
> 2014-01-16 17:01:18,369 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-73:null) Vm cpu utilization 23.8075
> 2014-01-16 17:01:18,370 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-73:null) Vm cpu utilization 10.09875
> 2014-01-16 17:01:18,370 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-73:null) Vm cpu utilization 0.29828125
> 2014-01-16 17:01:18,370 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-73:null) Vm cpu utilization 2.6504
> 2014-01-16 17:01:18,370 DEBUG [xen.resource.CitrixResourceBase]
> (DirectAgent-73:null) Vm cpu utilization 0.8375
> 2014-01-16 17:01:18,507 WARN  [xen.resource.CitrixResourceBase]
> (DirectAgent-73:null) Error while collecting disk stats from :
> You gave an invalid object reference.  The object may have recently been
> deleted.  The class parameter gives the type of reference given, and the
> handle parameter echoes the bad value given.
> at com.xensource.xenapi.Types.checkResponse(Types.java:209)
> at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909)
> at com.xensource.xenapi.VBDMetrics.getIoReadKbs(VBDMetrics.java:210)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.getVmStats(CitrixResourceBase.java:2791)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:2691)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:497)
> at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:701)
> 2014-01-16 17:01:18,509 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-73:null) Seq 2-1599340596: Response Received:
>
>
> Also, Because we were planning to upgrade the pool using Local-Storage we
> start moving VM into another Primary Storage using regular procedure of
> turning off Instances, and moving them as Admin account. this keep failing
> but also delete Instance DISK which result of having data lost.
>
> Now, we can't see our hosts list and System VM list from the
> Infrastructure tab (see attachements), we only see ERROR.
>
> here is the apilog.log when trying to show hosts:
>
> 2014-01-16 17:13:35,337 INFO  [cloud.api.ApiServer]
> (catalina-exec-18:null) (userId=2 accountId=2
> sessionId=4F907F8E77BE76ADF46BB4FBE6B23BC0) 172.24.0.20 -- GET
> command=listHosts&response=json&sessionkey=tPdf1uSuogiM1ubmRFuPuFV%2FLzM%3D&page=1&pageSize=20&type=routing&listAll=true&_=1389910415201
> 530 null
>
> is their any other logs to look at to understands what's broken because
> the upper stacktrace is clue

Re: Change SCSI type in VMware

[Sean Hamilton]

Hi Sateesh,

Thanks for picking this up. 
I tried editing the SCSI type in the VM, but CloudStack changes it back when 
the VM is started. 

Thanks,
Sean

> On 17 Jan 2014, at 09:34, Sateesh Chodapuneedi 
>  wrote:
> 
> Sean, 
> 
> I have picked up this task, CLOUDSTACK-4787.
> By early next week, I will comeup with proposal to support subtypes of scsi 
> disk controllers in CloudStack for vSphere.
> 
>> Is there a workaround for this issue?
> I think yes. Try changing the controller type to Lsi Logic SAS and start the 
> VM to continue the installation from ISO.
> Please let me know how it goes.
> 
> Regards,
> Sateesh
> 
>> -Original Message-
>> From: Sean Hamilton [mailto:s...@seanhamilton.co.uk]
>> Sent: 16 January 2014 22:58
>> To: us...@cloudstack.apache.org
>> Subject: Re: Change SCSI type in VMware
>> 
>> Thanks!
>> 
>> 
>>> On 16 January 2014 09:03, sebgoa  wrote:
>>> 
>>> 
>>> On Jan 15, 2014, at 11:01 AM, Sean Hamilton 
>>> wrote:
>>> 
 It's out of my league too. Hope this comes in a release soon.
>>> 
>>> I change the ticket to a 'Bug' and added 4.3 has a branch where the
>>> problem exists.
>>> It should give it some visibility in JIRA.
>>> 
>>> Hopefully a fix soon
>>> 
>>> -sebastien
>>> 
 
> On 9 January 2014 11:26, Erik Weber  wrote:
> 
> On Thu, Jan 9, 2014 at 12:07 PM, Sean Hamilton
> > wrote:
> 
>> Hi Guys,
>> 
>> One of our users is trying to use Windows Server 2012 R2.
>> On install they can't see the disk attached. I checked and it
>> looks
>>> like
>> Microsoft removed the LSI Logic Parallel driver from that OS.
>> Changing
> the
>> storage adapter to LSI Logic SAS should work (and does work in VMware).
> In
>> CloudStack there is no option for this. I see a feature open for it:
>> https://issues.apache.org/jira/browse/CLOUDSTACK-4787
>> 
>> Does anyone have a workaround? Even if I change the value in
>> VMware,
>>> when
>> CloudStack powers the instance on, it changes back to Parallel.
>> 
>> I'd really like to offer support for the latest Operating Systems
>> in CloudStack and was wondering if anyone else was hit by the same issue?
> 
> I haven't been able to find a workaround yet.
> I did take a look in eclipse and noticed that the vmware jars do
> have
>>> the
> appropriate setting for it, it's just a matter of adding it to the
> cloudstack ui, storing and using it.
> 
> However, that's out of my league.
> 
> 
> --
> Erik
>>> 
>>> 

RE: Hyper-V

[Paul Angus]

Hi Deepdev,

I've been working on client's projects the last couple of days, i'll be 
rebuilding my lab with advanced networking over the weekend.

I'll let you know how I get on.

Sent from Samsung tablet


 Original message 
From: Devdeep Singh
Date:17/01/2014 10:37 (GMT+00:00)
To: dev@cloudstack.apache.org
Cc: Donal Lafferty ,Rajesh Battala ,Anshul Gangwar
Subject: RE: Hyper-V

Hi Paul,

Did you get a chance to try it in Advanced mode? Did it work for you? Anshul 
recently made a change to secure the communication between the management 
server and the agent. If you try with the latest changes you'll have to install 
a certificate so that the management server can talk to the agent. Following 
link [1] will tell you how to go about it.

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Manually+Creating+and+installing+self+signed+certificate+for+CloudStack+Management+Server+communication+with+Hyper-V+agent

Regards,
Devdeep

-Original Message-
From: Devdeep Singh [mailto:devdeep.si...@citrix.com]
Sent: Thursday, January 16, 2014 7:05 PM
To: dev@cloudstack.apache.org
Cc: Donal Lafferty; Rajesh Battala; Anshul Gangwar
Subject: RE: Hyper-V

Hi Paul,

>From the logs it looks like you have setup the zone in Basic mode. Basic mode 
>is right now not supported for Hyper-V. Can you set it up in Advanced mode and 
>see if it works?

Regards,
Devdeep

P.S. I just tried setting up the zone in Basic mode and confirmed I got the 
same exception.

-Original Message-
From: Paul Angus [mailto:paul.an...@shapeblue.com]
Sent: Thursday, January 16, 2014 5:25 PM
To: dev@cloudstack.apache.org
Cc: Donal Lafferty; Rajesh Battala; Anshul Gangwar
Subject: RE: Hyper-V

I've got the System VMs creating, but not starting now...

Error seems to be:
POST response 
is[{"com.cloud.agent.api.StartAnswer":{"result":false,"details":"com.cloud.agent.api.StartCommand
 fail on exceptionObject reference not set to an instance of an object

Agent log:
http://pastebin.com/zhfXia9v

mgmt. log:
http://pastebin.com/ZUjBgqX8

Regards,

Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus 
paul.an...@shapeblue.com

-Original Message-
From: Devdeep Singh [mailto:devdeep.si...@citrix.com]
Sent: 15 January 2014 02:57
To: dev@cloudstack.apache.org
Cc: Donal Lafferty; Rajesh Battala; Anshul Gangwar
Subject: RE: Hyper-V

Hi Paul,

I have put in a fix for the issue with local storage that you reported earlier 
[1]. Please pull the latest changes and try. It should work now. I'll look into 
the error you are facing with shared and let you know once it is fixed.

[1] https://issues.apache.org/jira/browse/CLOUDSTACK-5869

Regards,
Devdeep

From: Paul Angus [mailto:paul.an...@shapeblue.com]
Sent: Tuesday, January 14, 2014 9:19 PM
To: dev@cloudstack.apache.org
Cc: Donal Lafferty; Rajesh Battala; Anshul Gangwar
Subject: Hyper-V

Guys,

Primary storage local or shared is still giving me grief.

See the error below from the agent log when trying to create a system VM. the 
final error is 'org.apache.cloudstack.storage.command.CopyCommand failed on 
exception, net use of share 10.0.1.27/hypervPri/storfailed with Error: 
Unknown, 1219",'
The share is \\10.0.1.27\hypervPri\stor in 
UNC notation.


2014-01-14 15:40:12,566 [6] INFO  HypervResource.HypervResourceController 
[cc482c9e-0d97-4be8-9dc8-2e546bdb00c1] - 
org.apache.cloudstack.storage.command.CopyCommand{
  "srcTO": {
"org.apache.cloudstack.storage.to.TemplateObjectTO": {
  "path": "template/tmpl/1/9/",
  "origUrl": 
"http://download.cloud.com/templates/4.3/systemvm64template-2013-12-23-hyperv.vhd.bz2";,
  "uuid": "18767718-7d1b-11e3-b742-0050568b4d4c",
  "id": 9,
  "format": "VHD",
  "accountId": 1,
  "checksum": "5df45ee6ebe1b703a8805f4e1f4d0818",
  "hvm": false,
  "displayText": "SystemVM Template (HyperV)",
  "imageDataStore": {
"com.cloud.agent.api.to.NfsTO": {
 "_url": 
"cifs://10.0.100.5/stor_Cloud/Secondary/ACS43?user=hyperv&password=hyperv&domain=angusnet",
  "_role": "Image"
}
  },
  "name": "routing-9",
  "hypervisorType": "Hyperv"
}
  },
  "destTO": {
"org.apache.cloudstack.storage.to.TemplateObjectTO": {
  "origUrl": 
"http://download.cloud.com/templates/4.3/systemvm64template-2013-12-23-hyperv.vhd.bz2";,
  "uuid": "18767718-7d1b-11e3-b742-0050568b4d4c",
  "id": 9,
  "format": "VHD",
  "accountId": 1,
  "checksum": "5df45ee6ebe1b703a8805f4e1f4d0818",
  "hvm": false,
  "displayText": "SystemVM Template (HyperV)",
  "imageDataStore": {
"org.apache.cloudstack.storage.to.PrimaryDataStoreTO": {
  "uuid": "2bcff176-e5f3-350e-936a-7ee19a0e8658",
  "id": 2,
  "poolType": "NetworkFilesystem",
  "host": "10.0.1.27",
  "path": 
"/hypervPri/stor?user=hyperv&password=hyperv13!&domain=angusnet.local",
  "port": 445,
  "url": 
"Network

Build failed in Jenkins: build-master-noredist #2122

[jenkins]

See 

Changes:

[Devdeep Singh] CLOUDSTACK-5894: A template created from a volume on hyper-v 
became unusable after

--
[...truncated 53143 lines...]
986/1332 KB   
990/1332 KB   
994/1332 KB   
998/1332 KB   
1002/1332 KB   
1006/1332 KB   
1010/1332 KB   
1014/1332 KB   
1018/1332 KB   
1022/1332 KB   
1026/1332 KB   
1030/1332 KB   
1034/1332 KB   
1038/1332 KB   
1042/1332 KB   
1046/1332 KB   
1050/1332 KB   
1054/1332 KB   
1058/1332 KB   
1062/1332 KB   
1066/1332 KB   
1070/1332 KB   
1074/1332 KB   
1078/1332 KB   
1082/1332 KB   
1086/1332 KB   
1090/1332 KB   
1094/1332 KB   
1098/1332 KB   
1102/1332 KB   
1106/1332 KB   
1110/1332 KB   
1114/1332 KB   
1118/1332 KB   
1122/1332 KB   
1126/1332 KB   
1130/1332 KB   
1134/1332 KB   
1138/1332 KB   
1142/1332 KB   
1146/1332 KB   
1150/1332 KB   
1154/1332 KB   
1158/1332 KB   
1162/1332 KB   
1166/1332 KB   
1170/1332 KB   
1174/1332 KB   
1178/1332 KB   
1182/1332 KB   
1186/1332 KB   
1190/1332 KB   
1194/1332 KB   
1198/1332 KB   
1202/1332 KB   
1206/1332 KB   
1210/1332 KB   
1214/1332 KB   
1218/1332 KB   
1222/1332 KB   
1226/1332 KB   
1230/1332 KB   
1234/1332 KB   
1238/1332 KB   
1242/1332 KB   
1246/1332 KB   
1250/1332 KB   
1254/1332 KB   
1258/1332 KB   
1262/1332 KB   
1266/1332 KB   
1270/1332 KB   
1274/1332 KB   
1278/1332 KB   
1282/1332 KB   
1286/1332 KB   
1290/1332 KB   
1294/1332 KB   
1298/1332 KB   
1302/1332 KB   
1306/1332 KB   
1310/1332 KB   
1314/1332 KB   
1318/1332 KB   
1322/1332 KB   
1326/1332 KB   
1330/1332 KB   
1332/1332 KB   
   
Downloaded: 
http://repo.maven.apache.org/maven2/xerces/xercesImpl/2.10.0/xercesImpl-2.10.0.jar
 (1332 KB at 4703.9 KB/sec)
[WARNING] Invalid project model for artifact 
[addressing:org.apache.axis2:1.5.4]. It will be ignored by the remote resources 
Mojo.
[WARNING] Invalid project model for artifact [bcprov-jdk14:bouncycastle:140]. 
It will be ignored by the remote resources Mojo.
[WARNING] Invalid project model for artifact [opensaml1:org.opensaml:1.1]. It 
will be ignored by the remote resources Mojo.
[WARNING] Invalid project model for artifact [commons-lang:commons-lang:2.3]. 
It will be ignored by the remote resources Mojo.
[WARNING] Invalid project model for artifact 
[rampart-trust:org.apache.rampart:1.5.1]. It will be ignored by the remote 
resources Mojo.
[WARNING] Invalid project model for artifact 
[rampart-policy:org.apache.rampart:1.5.1]. It will be ignored by the remote 
resources Mojo.
[WARNING] Invalid project model for artifact 
[xmlsec:org.apache.santuario:1.4.2]. It will be ignored by the remote resources 
Mojo.
[WARNING] Invalid project model for artifact [mex:org.apache.axis2:1.5.4]. It 
will be ignored by the remote resources Mojo.
[WARNING] Invalid project model for artifact 
[axiom-dom:org.apache.ws.commons.axiom:1.2.10]. It will be ignored by the 
remote resources Mojo.
[WARNING] Invalid project model for artifact 
[axis2-mtompolicy:org.apache.axis2:1.5.4]. It will be ignored by the remote 
resources Mojo.
[INFO] 
[INFO] --- maven-antrun-plugin:1.7:run (generate-resource) @ cloud-awsapi ---
[INFO] Executing tasks

main:
 [copy] Copying 3 files to 

[INFO] Executed tasks
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-awsapi ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 2 resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ cloud-awsapi 
---
[INFO] Compiling 1295 source files to 

[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] error: error reading 
/jenkins/.m2/repository/org/apache/axis2/mex/1.5.4/mex-1.5.4-impl.jar; error in 
opening zip file
[ERROR] error: error reading 
/jenkins/.m2/repository/org/apache/axis2/axis2-mtompolicy/1.5.4/axis2-mtompolicy-1.5.4.jar;
 error in opening zip file
[ERROR] error: error reading 
/jenkins/.m2/repository/org/apache/ws/commons/axiom/axiom-dom/1.2.10/axiom-dom-1.2.10.jar;
 error in opening zip file
[ERROR] error: error reading 
/jenkins/.m2/repository/org/opensaml/opensaml1/1.1/opensaml1-1.1.jar; error in 
opening zip file
[ERROR] error: error reading 
/jenkins/.m2/repository/commons-lang/commons-lang/2.3/commons-lang-2.3.jar; 
error in opening zip file
[INFO] 5 errors 
[INFO] -
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache CloudStack 

Author Search Inquiry - CloudStack Book for Packt Publishing

[Sam Wood]

Dear all, 



My name is Sam Wood, and I’m an Acquisition Editor with Packt Publishing. I was 
kindly given this address by Sebastien Goasguen as a place I might want to 
email in order to find people potentially interested in authoring a book we 
currently have commissioned on CloudStack. 



The book’s working title is CloudStack Cloud Computing Cookbook , and it’s 
aimed at an audience with an existing knowledge of the CloudStack basics. It is 
intended to be written in Packt’s Cookbook format, which have a theory-light 
‘recipe’ based approach of targeted practical advice. 



If anyone was interested in authoring this title and would like more details on 
the opportunity, it would be great to hear from them. I can be contacted 
through this email address. 



Thank you for your time. 



Best regards, 

Sam Wood 

Acquisition Editor 
[ Packt Publishing ] 

Find Us: www.packtpub.com 
Follow Us: @packtpub 

Packt Publishing Limited 
Registered Office: Livery Place, 35 Livery Street, Birmingham, West Midlands, 
B3 2PB 
Registered in England - Number 4759694 

This E-mail is confidential. It may also be legally privileged. If you are not 
the addressee you may not copy, forward, disclose or use any part of it. If you 
have received this message in error, please delete it and all copies from your 
system and notify the sender immediately by return E-mail. Whilst Packt 
Publishing Ltd take every reasonable precaution to avoid the transfer of 
software viruses or defects that may cause damage to computer systems; it is 
the responsibility of the recipient to ensure that all emails and attachments 
received, are free from infection. 

systemvm templates

[Abhinandan Prateek]

While trying to build systemvm templates I noticed that the urls to download 
the debian images are invalid as in definition.rb in respective folders:

For 64 bit template  
http://cdimage.debian.org/mirror/cdimage/archive/7.0.0/i386/iso-cd/debian-7.0.0-i386-netinst.iso
For 32 bit template  
http://cdimage.debian.org/mirror/cdimage/archive/7.0.0/i386/iso-cd/debian-7.0.0-i386-netinst.iso

I will be updating these to following respectively, once I have a successful 
local build:

http://ftp.acc.umu.se/mirror/cdimage/release/7.3.0/i386/iso-cd/debian-7.3.0-i386-netinst.iso
   MD5: 04c58f30744e64a0459caf7d7cace479
http://ftp.acc.umu.se/mirror/cdimage/release/7.3.0/ia64/iso-cd/debian-7.3.0-ia64-netinst.iso
  MD5: a6b93666a5393334accb7ac4ee28d949

Not sure if jenkins job is building the right templates now ?

-abhi

Jenkins build is back to normal : build-master-noredist #2123

[jenkins]

See 

Revert "update packages list before getting jre 7"

[Hugo Trippaers]

Hey guys,

I just reverted commit fa6536152a17dfd03b6eb10b2a1e0868fc9e134c

The branch 4.3 is a release branch, not a playground. We are inches away from a 
release, this means that nothing goes into the branch without being expressly 
permitted by the release manager. This case is even worse as the change wasn’t 
even made in master, the leading branch.

Just a general reminder about the process.

1. Create a ticket for your bug (if its not a bug, its not going to be in 4.3 
anyway)
2. Make your changes in master
3. Test them on master
4. Send mail to dev list to ask permission from the release manager to back 
port to 4.3 and include the test result

Please stick to this game plan, so we can have a speedy release of 4.3.


Cheers,

Hugo

Re: Issues after upgrading CS from 4.1 to 4.2.1 managing XenServer 6.0.2 clusters

[Pierre-Luc Dion]

Should I test replacing xapi-5.6.100-1-20130125.183249-474.jar by the one
from 4.3 branch : xapi-5.6.100-1-SNAPSHOT.jar ?

Also we did not upgrade XenServer which is currently using 6.0.2. did
upgrade Cloudstack from 4.1.0 to 4.2.1





Pierre-Luc Dion
Architecte de Solution Cloud | Cloud Solutions Architect
514-447-3456, 1101
- - -

*CloudOps*420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_


On Fri, Jan 17, 2014 at 9:59 AM, Wei ZHOU  wrote:

> same issue: CLOUDSTACK-5834
>
>
> 2014/1/17 Pierre-Luc Dion 
>
> > Hi,
> >
> > We've upgrade our Cloudstack environment from 4.1 to 4.2.1, it is
> > currently managing XenServer 6.0.2 clusters.
> >
> > 1. Since we have upgraded to 4.2.1 we noticed that Secondary Storage Name
> > have been rename and we now see UUID's of SS.
> > 2. On one cluster that is using local-Storage and Shared Storage we have
> > removed on host from the XenServer Pool, since then,  this error keep
> > repeating in the management-server.log:
> >
> > 2014-01-16 17:01:17,898 DEBUG [agent.manager.DirectAgentAttache]
> > (DirectAgent-437:null) Seq 1-590413869: Response Received:
> > 2014-01-16 17:01:17,898 DEBUG [agent.transport.Request]
> > (StatsCollector-2:null) Seq 1-590413869: Received:  { Ans: , MgmtId:
> > 152067623530867, via: 1, Ver: v1, Flags: 10, { GetVmStatsAnswer } }
> > 2014-01-16 17:01:17,949 DEBUG [agent.manager.DirectAgentAttache]
> > (DirectAgent-73:null) Seq 2-1599340596: Executing request
> > 2014-01-16 17:01:18,191 DEBUG [agent.manager.DirectAgentAttache]
> > (DirectAgent-320:null) Ping from 69
> > 2014-01-16 17:01:18,369 DEBUG [xen.resource.CitrixResourceBase]
> > (DirectAgent-73:null) Vm cpu utilization 0.0064062499
> > 2014-01-16 17:01:18,369 DEBUG [xen.resource.CitrixResourceBase]
> > (DirectAgent-73:null) Vm cpu utilization 12.9175
> > 2014-01-16 17:01:18,369 DEBUG [xen.resource.CitrixResourceBase]
> > (DirectAgent-73:null) Vm cpu utilization 24.08
> > 2014-01-16 17:01:18,369 DEBUG [xen.resource.CitrixResourceBase]
> > (DirectAgent-73:null) Vm cpu utilization 0.29504
> > 2014-01-16 17:01:18,369 DEBUG [xen.resource.CitrixResourceBase]
> > (DirectAgent-73:null) Vm cpu utilization 23.8075
> > 2014-01-16 17:01:18,370 DEBUG [xen.resource.CitrixResourceBase]
> > (DirectAgent-73:null) Vm cpu utilization 10.09875
> > 2014-01-16 17:01:18,370 DEBUG [xen.resource.CitrixResourceBase]
> > (DirectAgent-73:null) Vm cpu utilization 0.29828125
> > 2014-01-16 17:01:18,370 DEBUG [xen.resource.CitrixResourceBase]
> > (DirectAgent-73:null) Vm cpu utilization 2.6504
> > 2014-01-16 17:01:18,370 DEBUG [xen.resource.CitrixResourceBase]
> > (DirectAgent-73:null) Vm cpu utilization 0.8375
> > 2014-01-16 17:01:18,507 WARN  [xen.resource.CitrixResourceBase]
> > (DirectAgent-73:null) Error while collecting disk stats from :
> > You gave an invalid object reference.  The object may have recently been
> > deleted.  The class parameter gives the type of reference given, and the
> > handle parameter echoes the bad value given.
> > at com.xensource.xenapi.Types.checkResponse(Types.java:209)
> > at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
> > at
> >
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909)
> > at com.xensource.xenapi.VBDMetrics.getIoReadKbs(VBDMetrics.java:210)
> > at
> >
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.getVmStats(CitrixResourceBase.java:2791)
> > at
> >
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:2691)
> > at
> >
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:497)
> > at
> >
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
> > at
> >
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> > at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> > at
> >
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> > at
> >
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > at java.lang.Thread.run(Thread.java:701)
> > 2014-01-16 17:01:18,509 DEBUG [agent.manager.DirectAgentAttache]
> > (DirectAgent-73:null) Seq 2-1599340596: Response Received:
> >
> >
> > Also, Because we were planning to upgrade the pool using Local-Storage we
> > start moving VM into another Primary Storage using regular procedure of
> > turning off Instances, and moving them as Admin account. this keep
> failing
> > but also delete Insta

Re: systemvm templates

[Hugo Trippaers]

Abhi,

I have the debian 7.0.0 isis local on the jenkins server, so we don’t depend on 
the external URLs.

Do you want to switch master to the new image? No trouble for me to make it 
happen.

Cheers,

Hugo

On 17 jan. 2014, at 17:12, Abhinandan Prateek  
wrote:

> 
> While trying to build systemvm templates I noticed that the urls to download 
> the debian images are invalid as in definition.rb in respective folders:
> 
> For 64 bit template  
> http://cdimage.debian.org/mirror/cdimage/archive/7.0.0/i386/iso-cd/debian-7.0.0-i386-netinst.iso
> For 32 bit template  
> http://cdimage.debian.org/mirror/cdimage/archive/7.0.0/i386/iso-cd/debian-7.0.0-i386-netinst.iso
> 
> I will be updating these to following respectively, once I have a successful 
> local build:
> 
> http://ftp.acc.umu.se/mirror/cdimage/release/7.3.0/i386/iso-cd/debian-7.3.0-i386-netinst.iso
>MD5: 04c58f30744e64a0459caf7d7cace479
> http://ftp.acc.umu.se/mirror/cdimage/release/7.3.0/ia64/iso-cd/debian-7.3.0-ia64-netinst.iso
>   MD5: a6b93666a5393334accb7ac4ee28d949
> 
> Not sure if jenkins job is building the right templates now ?
> 
> -abhi
> 
> 
> 

Re: Revert "update packages list before getting jre 7"

[Abhinandan Prateek]

I have reverted another related one
fc2e7ec70a1cc48a10a168ec3df607b49a7bcdf6, that was updating the jre to
version 7. 

-abhi

On 17/01/14 10:11 pm, "Hugo Trippaers"  wrote:

>Hey guys,
>
>I just reverted commit fa6536152a17dfd03b6eb10b2a1e0868fc9e134c
>
>The branch 4.3 is a release branch, not a playground. We are inches away
>from a release, this means that nothing goes into the branch without
>being expressly permitted by the release manager. This case is even worse
>as the change wasn¹t even made in master, the leading branch.
>
>Just a general reminder about the process.
>
>1. Create a ticket for your bug (if its not a bug, its not going to be in
>4.3 anyway)
>2. Make your changes in master
>3. Test them on master
>4. Send mail to dev list to ask permission from the release manager to
>back port to 4.3 and include the test result
>
>Please stick to this game plan, so we can have a speedy release of 4.3.
>
>
>Cheers,
>
>Hugo

Re: systemvm templates

[Abhinandan Prateek]

Hugo,

  First of all my bad that I jumped the gun on jre7 change. I will be
testing the full build on master and then update the urls and other
changes.
In the current template jre7 package is not available by default, needs
apt-get update. jre7 is a absolute necessity for VMWare template.

Once I have a successful local build I will update the thread.

-abhi


On 17/01/14 10:20 pm, "Hugo Trippaers"  wrote:

>Abhi,
>
>I have the debian 7.0.0 isis local on the jenkins server, so we don¹t
>depend on the external URLs.
>
>Do you want to switch master to the new image? No trouble for me to make
>it happen.
>
>Cheers,
>
>Hugo
>
>On 17 jan. 2014, at 17:12, Abhinandan Prateek
> wrote:
>
>> 
>> While trying to build systemvm templates I noticed that the urls to
>>download the debian images are invalid as in definition.rb in respective
>>folders:
>> 
>> For 64 bit template
>>http://cdimage.debian.org/mirror/cdimage/archive/7.0.0/i386/iso-cd/debian
>>-7.0.0-i386-netinst.iso
>> For 32 bit template
>>http://cdimage.debian.org/mirror/cdimage/archive/7.0.0/i386/iso-cd/debian
>>-7.0.0-i386-netinst.iso
>> 
>> I will be updating these to following respectively, once I have a
>>successful local build:
>> 
>> 
>>http://ftp.acc.umu.se/mirror/cdimage/release/7.3.0/i386/iso-cd/debian-7.3
>>.0-i386-netinst.iso   MD5: 04c58f30744e64a0459caf7d7cace479
>> 
>>http://ftp.acc.umu.se/mirror/cdimage/release/7.3.0/ia64/iso-cd/debian-7.3
>>.0-ia64-netinst.iso  MD5: a6b93666a5393334accb7ac4ee28d949
>> 
>> Not sure if jenkins job is building the right templates now ?
>> 
>> -abhi
>> 
>> 
>> 
>

Re: Revert "update packages list before getting jre 7"

[Hugo Trippaers]

Thanks Abhi,

Can you raise the bug and apply them on master?  Maybe it’s also good to write 
to the list which this upgrade is required. There is a thread on upgrading to 
java 7 that might be interesting to refer to.

Cheers,

Hugo


On 17 jan. 2014, at 17:58, Abhinandan Prateek  
wrote:

> I have reverted another related one
> fc2e7ec70a1cc48a10a168ec3df607b49a7bcdf6, that was updating the jre to
> version 7. 
> 
> -abhi
> 
> On 17/01/14 10:11 pm, "Hugo Trippaers"  wrote:
> 
>> Hey guys,
>> 
>> I just reverted commit fa6536152a17dfd03b6eb10b2a1e0868fc9e134c
>> 
>> The branch 4.3 is a release branch, not a playground. We are inches away
>> from a release, this means that nothing goes into the branch without
>> being expressly permitted by the release manager. This case is even worse
>> as the change wasn¹t even made in master, the leading branch.
>> 
>> Just a general reminder about the process.
>> 
>> 1. Create a ticket for your bug (if its not a bug, its not going to be in
>> 4.3 anyway)
>> 2. Make your changes in master
>> 3. Test them on master
>> 4. Send mail to dev list to ask permission from the release manager to
>> back port to 4.3 and include the test result
>> 
>> Please stick to this game plan, so we can have a speedy release of 4.3.
>> 
>> 
>> Cheers,
>> 
>> Hugo
> 

Error starting management server with latest 4.3

[Prabhakaran Ganesan]

Hi,

I created  a new sandbox on 4.3, built the source and tried starting the 
management server yesterday. But I ran into the following error. I thought it 
could be something intermittent and tried with a fresh sandbox today. I still 
see the same problem. The build environment is based on Centos 6.4 i686. Any 
ideas?

Thanks
Prabhakar

INFO  [c.c.s.GsonHelper] (main:null) Default Builder inited.
INFO  [c.c.u.c.ComponentContext] (main:null) Setup Spring Application context
INFO  [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Running system 
integrity checker com.cloud.upgrade.DatabaseIntegrityChecker@77857
INFO  [c.c.u.DatabaseIntegrityChecker] (main:null) Grabbing lock to check for 
database integrity.
INFO  [c.c.u.DatabaseIntegrityChecker] (main:null) Performing database 
integrity check
INFO  [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Running system 
integrity checker 
org.apache.cloudstack.utils.identity.ManagementServerNode@1f94b12
INFO  [o.a.c.s.l.CloudStackExtendedLifeCycle] (main:null) Configuring 
CloudStack Components
2014-01-17 04:17:07.466:WARN::Failed startup of context 
org.mortbay.jetty.plugin.Jetty6PluginWebAppContext@112a02e{/client,/root/cloudstack/client/target/generated-webapp}
org.springframework.context.ApplicationContextException: Failed to start bean 
'cloudStackLifeCycle'; nested exception is net.sf.ehcache.CacheException: 
Unable to create CacheManagerPeerListener. Initial cause was 
sdk-vee-appliance-2.englab.juniper.net: sdk-vee-appliance-2.englab.juniper.net
at 
org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:170)
at 
org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51)
at 
org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:339)
at 
org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:143)
at 
org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:108)
at 
org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:945)
at 
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:141)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with(DefaultModuleDefinitionSet.java:119)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:239)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:244)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:244)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:227)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContexts(DefaultModuleDefinitionSet.java:115)
at 
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load(DefaultModuleDefinitionSet.java:78)
at 
org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules(ModuleBasedContextFactory.java:37)
at 
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:69)
at 
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:56)
at 
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.(CloudStackSpringContext.java:60)
at 
org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener.contextInitialized(CloudStackContextLoaderListener.java:51)
at 
org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:549)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:136)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499)
at 
org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at 
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at 
org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at 
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(

Re: systemvm templates

[Milamber]

Le 17/01/2014 16:12, Abhinandan Prateek a ecrit :

While trying to build systemvm templates I noticed that the urls to download 
the debian images are invalid as in definition.rb in respective folders:

For 64 bit template  
http://cdimage.debian.org/mirror/cdimage/archive/7.0.0/i386/iso-cd/debian-7.0.0-i386-netinst.iso
For 32 bit template  
http://cdimage.debian.org/mirror/cdimage/archive/7.0.0/i386/iso-cd/debian-7.0.0-i386-netinst.iso

I will be updating these to following respectively, once I have a successful 
local build:

http://ftp.acc.umu.se/mirror/cdimage/release/7.3.0/i386/iso-cd/debian-7.3.0-i386-netinst.iso
   MD5: 04c58f30744e64a0459caf7d7cace479
http://ftp.acc.umu.se/mirror/cdimage/release/7.3.0/ia64/iso-cd/debian-7.3.0-ia64-netinst.iso
  MD5: a6b93666a5393334accb7ac4ee28d949


Please note : choice "amd64" for 64 bits on Intel x86 arch, not "ia64" 
(Intel Itanium 64 bits)


http://ftp.acc.umu.se/mirror/cdimage/release/7.3.0/amd64/iso-cd/debian-7.3.0-amd64-netinst.iso




Not sure if jenkins job is building the right templates now ?

-abhi

Re: systemvm templates

[Rohit Yadav]

Hi Abhi,

If someone has the isos downloaded locally the build won't fail as
vagrant uses the (previously downloaded) iso with valid md5checksum
instead of downloading from the url, so probably the build on jenkins
must not be failing and should be fine. For someone who's doing a
fresh build on their system it must be fixed as the debian iso urls
may move from time to time.

Regards.

On Fri, Jan 17, 2014 at 9:42 PM, Abhinandan Prateek
 wrote:
>
> While trying to build systemvm templates I noticed that the urls to download 
> the debian images are invalid as in definition.rb in respective folders:
>
> For 64 bit template  
> http://cdimage.debian.org/mirror/cdimage/archive/7.0.0/i386/iso-cd/debian-7.0.0-i386-netinst.iso
> For 32 bit template  
> http://cdimage.debian.org/mirror/cdimage/archive/7.0.0/i386/iso-cd/debian-7.0.0-i386-netinst.iso
>
> I will be updating these to following respectively, once I have a successful 
> local build:
>
> http://ftp.acc.umu.se/mirror/cdimage/release/7.3.0/i386/iso-cd/debian-7.3.0-i386-netinst.iso
>MD5: 04c58f30744e64a0459caf7d7cace479
> http://ftp.acc.umu.se/mirror/cdimage/release/7.3.0/ia64/iso-cd/debian-7.3.0-ia64-netinst.iso
>   MD5: a6b93666a5393334accb7ac4ee28d949
>
> Not sure if jenkins job is building the right templates now ?
>
> -abhi
>
>
>

Re: Author Search Inquiry - CloudStack Book for Packt Publishing

[Rohit Yadav]

Hi Sam,

I don't have time to work on the book while I had thought about
something like this many times. So, instead I would like to contribute
by helping the author (whoever they may be) by proof-reading and
reviewing the book, perhaps I may contribute a chapter or two if the
author wants a helping hand. You know my email address now, so please
feel free to contact me but please no spam mails from packt. I check
email at twice a week.

About my work in the community -- I authored cloudmonkey which is
CloudStack's command line interface and had maintained a virtual
appliance called DevCloud2 (for helping developers/users build/test
cloudstack on their laptops/desktop in a VM), refactoring of api layer
etc. and have know how of CloudStack.

Regards.

On Fri, Jan 17, 2014 at 9:10 PM, Sam Wood  wrote:
>
>
> Dear all,
>
>
>
> My name is Sam Wood, and I’m an Acquisition Editor with Packt Publishing. I 
> was kindly given this address by Sebastien Goasguen as a place I might want 
> to email in order to find people potentially interested in authoring a book 
> we currently have commissioned on CloudStack.
>
>
>
> The book’s working title is CloudStack Cloud Computing Cookbook , and it’s 
> aimed at an audience with an existing knowledge of the CloudStack basics. It 
> is intended to be written in Packt’s Cookbook format, which have a 
> theory-light ‘recipe’ based approach of targeted practical advice.
>
>
>
> If anyone was interested in authoring this title and would like more details 
> on the opportunity, it would be great to hear from them. I can be contacted 
> through this email address.
>
>
>
> Thank you for your time.
>
>
>
> Best regards,
>
> Sam Wood
>
> Acquisition Editor
> [ Packt Publishing ]
>
> Find Us: www.packtpub.com
> Follow Us: @packtpub
>
> Packt Publishing Limited
> Registered Office: Livery Place, 35 Livery Street, Birmingham, West Midlands, 
> B3 2PB
> Registered in England - Number 4759694
>
> This E-mail is confidential. It may also be legally privileged. If you are 
> not the addressee you may not copy, forward, disclose or use any part of it. 
> If you have received this message in error, please delete it and all copies 
> from your system and notify the sender immediately by return E-mail. Whilst 
> Packt Publishing Ltd take every reasonable precaution to avoid the transfer 
> of software viruses or defects that may cause damage to computer systems; it 
> is the responsibility of the recipient to ensure that all emails and 
> attachments received, are free from infection.
>

RE: UI blocker

[Brian Federle]

Sorry, but cosmetic issues are not blockers :) It would only be a blockers if 
the functionality were NOT usable in any shape or form, for both testing and 
end use.

i.e. -- if the fields were completely missing or garbled in some way, I would 
agree that we can classify the bug as blocking release. Looking 'ugly', no -- I 
implemented the scrollbars because most times API keys, etc. are usually very 
long strings, causing overflow on some browsers and in most usability cases 
people are mainly needing to just copy/paste the values into other fields. It's 
not the most elegant solution I understand, but this is also a small facet of 
the whole UI experience.

I am going to ask everyone to PLEASE respect this when determining priority on 
UI bugs -- I know things like this are somewhat ugly, but there are only a 
small handful of full-time UI developers working on CloudStack and it makes our 
lives harder if everyone is marking trivial stuff as show-stoppers.

At any rate, if you still think this is a blocker, you can feel free to look 
into it yourself, in which case write a review request and I'll take a look at 
it.

-Brian

-Original Message-
From: Sebastien Goasguen [mailto:run...@gmail.com] 
Sent: Thursday, January 16, 2014 11:56 AM
To: Brian Federle
Cc: dev@cloudstack.apache.org; Jessica Wang
Subject: Re: UI blocker


On Jan 16, 2014, at 2:48 PM, Brian Federle  wrote:

>>> Did you happen to check the View Users page ? the api/secret keys display 
>>> is being truncated.
> 
> Yes, though to fix that I'll have to rework a bit of the detail view layout 
> to allow more flexible sizing for long strings. File that as a separate bug 
> for the next release and I'll take a look at it.

No, I will keep that as a blocker. it's worse than the previous UI, feel free 
to comment in the bug and grab it.

> 
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com] 
> Sent: Thursday, January 16, 2014 11:17 AM
> To: Brian Federle
> Cc: dev@cloudstack.apache.org; Jessica Wang
> Subject: Re: UI blocker
> 
> 
> On Jan 16, 2014, at 1:39 PM, Brian Federle  wrote:
> 
>> Don't see any issues in the screenshot you posted. The variation in font 
>> size and weight, color, etc. are used to show contrast between content and 
>> titles. Sorry but I do not see this as a blocker issue :) Though feel free 
>> to tweak the fonts yourself.
>> 
> 
> It looks strange to me, maybe that's just me. I see too many variations and 
> it's disturbing.
> 
> Did you happen to check the View Users page ? the api/secret keys display is 
> being truncated. 
> 
>> -Brian
>> 
>> -Original Message-
>> From: sebgoa [mailto:run...@gmail.com] 
>> Sent: Thursday, January 16, 2014 1:43 AM
>> To: dev@cloudstack.apache.org
>> Cc: Jessica Wang; Brian Federle
>> Subject: UI blocker
>> 
>> Hi, after testing 4.3 I entered a blocker due to UI issues:
>> https://issues.apache.org/jira/browse/CLOUDSTACK-5882
>> 
>> It would be good to discuss, 
>> 
>> thanks,
>> 
>> -Sebastien
> 

RE: UI blocker

[Jessica Wang]

> cosmetic issues are not blockers 

+1


-Original Message-
From: Brian Federle 
Sent: Friday, January 17, 2014 10:41 AM
To: dev@cloudstack.apache.org
Cc: Jessica Wang; Sonny Chhen
Subject: RE: UI blocker

Sorry, but cosmetic issues are not blockers :) It would only be a blockers if 
the functionality were NOT usable in any shape or form, for both testing and 
end use.

i.e. -- if the fields were completely missing or garbled in some way, I would 
agree that we can classify the bug as blocking release. Looking 'ugly', no -- I 
implemented the scrollbars because most times API keys, etc. are usually very 
long strings, causing overflow on some browsers and in most usability cases 
people are mainly needing to just copy/paste the values into other fields. It's 
not the most elegant solution I understand, but this is also a small facet of 
the whole UI experience.

I am going to ask everyone to PLEASE respect this when determining priority on 
UI bugs -- I know things like this are somewhat ugly, but there are only a 
small handful of full-time UI developers working on CloudStack and it makes our 
lives harder if everyone is marking trivial stuff as show-stoppers.

At any rate, if you still think this is a blocker, you can feel free to look 
into it yourself, in which case write a review request and I'll take a look at 
it.

-Brian

-Original Message-
From: Sebastien Goasguen [mailto:run...@gmail.com] 
Sent: Thursday, January 16, 2014 11:56 AM
To: Brian Federle
Cc: dev@cloudstack.apache.org; Jessica Wang
Subject: Re: UI blocker


On Jan 16, 2014, at 2:48 PM, Brian Federle  wrote:

>>> Did you happen to check the View Users page ? the api/secret keys display 
>>> is being truncated.
> 
> Yes, though to fix that I'll have to rework a bit of the detail view layout 
> to allow more flexible sizing for long strings. File that as a separate bug 
> for the next release and I'll take a look at it.

No, I will keep that as a blocker. it's worse than the previous UI, feel free 
to comment in the bug and grab it.

> 
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com] 
> Sent: Thursday, January 16, 2014 11:17 AM
> To: Brian Federle
> Cc: dev@cloudstack.apache.org; Jessica Wang
> Subject: Re: UI blocker
> 
> 
> On Jan 16, 2014, at 1:39 PM, Brian Federle  wrote:
> 
>> Don't see any issues in the screenshot you posted. The variation in font 
>> size and weight, color, etc. are used to show contrast between content and 
>> titles. Sorry but I do not see this as a blocker issue :) Though feel free 
>> to tweak the fonts yourself.
>> 
> 
> It looks strange to me, maybe that's just me. I see too many variations and 
> it's disturbing.
> 
> Did you happen to check the View Users page ? the api/secret keys display is 
> being truncated. 
> 
>> -Brian
>> 
>> -Original Message-
>> From: sebgoa [mailto:run...@gmail.com] 
>> Sent: Thursday, January 16, 2014 1:43 AM
>> To: dev@cloudstack.apache.org
>> Cc: Jessica Wang; Brian Federle
>> Subject: UI blocker
>> 
>> Hi, after testing 4.3 I entered a blocker due to UI issues:
>> https://issues.apache.org/jira/browse/CLOUDSTACK-5882
>> 
>> It would be good to discuss, 
>> 
>> thanks,
>> 
>> -Sebastien
> 

Re: systemvm templates

[Hugo Trippaers]

Hey ahbi,

Why is jre7 a requirement for the VmWare template? I'm running 4.3 with VMware 
now with the current template without any trouble. All software on the storage 
vm and console proxy is based on our code, which is all Jdk 6?

Cheers,

Hugo

Sent from my iPhone

> On 17 jan. 2014, at 18:07, Abhinandan Prateek  
> wrote:
> 
> Hugo,
> 
>  First of all my bad that I jumped the gun on jre7 change. I will be
> testing the full build on master and then update the urls and other
> changes.
> In the current template jre7 package is not available by default, needs
> apt-get update. jre7 is a absolute necessity for VMWare template.
> 
> Once I have a successful local build I will update the thread.
> 
> -abhi
> 
> 
>> On 17/01/14 10:20 pm, "Hugo Trippaers"  wrote:
>> 
>> Abhi,
>> 
>> I have the debian 7.0.0 isis local on the jenkins server, so we don¹t
>> depend on the external URLs.
>> 
>> Do you want to switch master to the new image? No trouble for me to make
>> it happen.
>> 
>> Cheers,
>> 
>> Hugo
>> 
>> On 17 jan. 2014, at 17:12, Abhinandan Prateek
>>  wrote:
>> 
>>> 
>>> While trying to build systemvm templates I noticed that the urls to
>>> download the debian images are invalid as in definition.rb in respective
>>> folders:
>>> 
>>> For 64 bit template
>>> http://cdimage.debian.org/mirror/cdimage/archive/7.0.0/i386/iso-cd/debian
>>> -7.0.0-i386-netinst.iso
>>> For 32 bit template
>>> http://cdimage.debian.org/mirror/cdimage/archive/7.0.0/i386/iso-cd/debian
>>> -7.0.0-i386-netinst.iso
>>> 
>>> I will be updating these to following respectively, once I have a
>>> successful local build:
>>> 
>>> 
>>> http://ftp.acc.umu.se/mirror/cdimage/release/7.3.0/i386/iso-cd/debian-7.3
>>> .0-i386-netinst.iso   MD5: 04c58f30744e64a0459caf7d7cace479
>>> 
>>> http://ftp.acc.umu.se/mirror/cdimage/release/7.3.0/ia64/iso-cd/debian-7.3
>>> .0-ia64-netinst.iso  MD5: a6b93666a5393334accb7ac4ee28d949
>>> 
>>> Not sure if jenkins job is building the right templates now ?
>>> 
>>> -abhi
> 

Re: UI blocker

[Chiradeep Vittal]

Have to agree with this.

On 1/17/14 10:42 AM, "Jessica Wang"  wrote:

>> cosmetic issues are not blockers
>
>+1
>
>
>-Original Message-
>From: Brian Federle
>Sent: Friday, January 17, 2014 10:41 AM
>To: dev@cloudstack.apache.org
>Cc: Jessica Wang; Sonny Chhen
>Subject: RE: UI blocker
>
>Sorry, but cosmetic issues are not blockers :) It would only be a
>blockers if the functionality were NOT usable in any shape or form, for
>both testing and end use.
>
>i.e. -- if the fields were completely missing or garbled in some way, I
>would agree that we can classify the bug as blocking release. Looking
>'ugly', no -- I implemented the scrollbars because most times API keys,
>etc. are usually very long strings, causing overflow on some browsers and
>in most usability cases people are mainly needing to just copy/paste the
>values into other fields. It's not the most elegant solution I
>understand, but this is also a small facet of the whole UI experience.
>
>I am going to ask everyone to PLEASE respect this when determining
>priority on UI bugs -- I know things like this are somewhat ugly, but
>there are only a small handful of full-time UI developers working on
>CloudStack and it makes our lives harder if everyone is marking trivial
>stuff as show-stoppers.
>
>At any rate, if you still think this is a blocker, you can feel free to
>look into it yourself, in which case write a review request and I'll take
>a look at it.
>
>-Brian
>
>-Original Message-
>From: Sebastien Goasguen [mailto:run...@gmail.com]
>Sent: Thursday, January 16, 2014 11:56 AM
>To: Brian Federle
>Cc: dev@cloudstack.apache.org; Jessica Wang
>Subject: Re: UI blocker
>
>
>On Jan 16, 2014, at 2:48 PM, Brian Federle 
>wrote:
>
 Did you happen to check the View Users page ? the api/secret keys
display is being truncated.
>> 
>> Yes, though to fix that I'll have to rework a bit of the detail view
>>layout to allow more flexible sizing for long strings. File that as a
>>separate bug for the next release and I'll take a look at it.
>
>No, I will keep that as a blocker. it's worse than the previous UI, feel
>free to comment in the bug and grab it.
>
>> 
>> -Original Message-
>> From: Sebastien Goasguen [mailto:run...@gmail.com]
>> Sent: Thursday, January 16, 2014 11:17 AM
>> To: Brian Federle
>> Cc: dev@cloudstack.apache.org; Jessica Wang
>> Subject: Re: UI blocker
>> 
>> 
>> On Jan 16, 2014, at 1:39 PM, Brian Federle 
>>wrote:
>> 
>>> Don't see any issues in the screenshot you posted. The variation in
>>>font size and weight, color, etc. are used to show contrast between
>>>content and titles. Sorry but I do not see this as a blocker issue :)
>>>Though feel free to tweak the fonts yourself.
>>> 
>> 
>> It looks strange to me, maybe that's just me. I see too many variations
>>and it's disturbing.
>> 
>> Did you happen to check the View Users page ? the api/secret keys
>>display is being truncated.
>> 
>>> -Brian
>>> 
>>> -Original Message-
>>> From: sebgoa [mailto:run...@gmail.com]
>>> Sent: Thursday, January 16, 2014 1:43 AM
>>> To: dev@cloudstack.apache.org
>>> Cc: Jessica Wang; Brian Federle
>>> Subject: UI blocker
>>> 
>>> Hi, after testing 4.3 I entered a blocker due to UI issues:
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-5882
>>> 
>>> It would be good to discuss,
>>> 
>>> thanks,
>>> 
>>> -Sebastien
>> 
>

RE: UI blocker

[Animesh Chaturvedi]

I agree not a blocker

-Original Message-
From: Jessica Wang [mailto:jessica.w...@citrix.com] 
Sent: Friday, January 17, 2014 10:43 AM
To: Brian Federle; dev@cloudstack.apache.org
Cc: Sonny Chhen
Subject: RE: UI blocker

> cosmetic issues are not blockers 

+1


-Original Message-
From: Brian Federle 
Sent: Friday, January 17, 2014 10:41 AM
To: dev@cloudstack.apache.org
Cc: Jessica Wang; Sonny Chhen
Subject: RE: UI blocker

Sorry, but cosmetic issues are not blockers :) It would only be a blockers if 
the functionality were NOT usable in any shape or form, for both testing and 
end use.

i.e. -- if the fields were completely missing or garbled in some way, I would 
agree that we can classify the bug as blocking release. Looking 'ugly', no -- I 
implemented the scrollbars because most times API keys, etc. are usually very 
long strings, causing overflow on some browsers and in most usability cases 
people are mainly needing to just copy/paste the values into other fields. It's 
not the most elegant solution I understand, but this is also a small facet of 
the whole UI experience.

I am going to ask everyone to PLEASE respect this when determining priority on 
UI bugs -- I know things like this are somewhat ugly, but there are only a 
small handful of full-time UI developers working on CloudStack and it makes our 
lives harder if everyone is marking trivial stuff as show-stoppers.

At any rate, if you still think this is a blocker, you can feel free to look 
into it yourself, in which case write a review request and I'll take a look at 
it.

-Brian

-Original Message-
From: Sebastien Goasguen [mailto:run...@gmail.com] 
Sent: Thursday, January 16, 2014 11:56 AM
To: Brian Federle
Cc: dev@cloudstack.apache.org; Jessica Wang
Subject: Re: UI blocker


On Jan 16, 2014, at 2:48 PM, Brian Federle  wrote:

>>> Did you happen to check the View Users page ? the api/secret keys display 
>>> is being truncated.
> 
> Yes, though to fix that I'll have to rework a bit of the detail view layout 
> to allow more flexible sizing for long strings. File that as a separate bug 
> for the next release and I'll take a look at it.

No, I will keep that as a blocker. it's worse than the previous UI, feel free 
to comment in the bug and grab it.

> 
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com] 
> Sent: Thursday, January 16, 2014 11:17 AM
> To: Brian Federle
> Cc: dev@cloudstack.apache.org; Jessica Wang
> Subject: Re: UI blocker
> 
> 
> On Jan 16, 2014, at 1:39 PM, Brian Federle  wrote:
> 
>> Don't see any issues in the screenshot you posted. The variation in font 
>> size and weight, color, etc. are used to show contrast between content and 
>> titles. Sorry but I do not see this as a blocker issue :) Though feel free 
>> to tweak the fonts yourself.
>> 
> 
> It looks strange to me, maybe that's just me. I see too many variations and 
> it's disturbing.
> 
> Did you happen to check the View Users page ? the api/secret keys display is 
> being truncated. 
> 
>> -Brian
>> 
>> -Original Message-
>> From: sebgoa [mailto:run...@gmail.com] 
>> Sent: Thursday, January 16, 2014 1:43 AM
>> To: dev@cloudstack.apache.org
>> Cc: Jessica Wang; Brian Federle
>> Subject: UI blocker
>> 
>> Hi, after testing 4.3 I entered a blocker due to UI issues:
>> https://issues.apache.org/jira/browse/CLOUDSTACK-5882
>> 
>> It would be good to discuss, 
>> 
>> thanks,
>> 
>> -Sebastien
> 

Re: IPv6 in VPC (was Re: IPv6 plan - questions)

[Chiradeep Vittal]

Yes, let's not shut out the ULA option.

For the LB "Public" interface, will this be just another tier? That is,
not an explicit public VLAN.

Since IPV6 support is still sparse, it is probably best that we support
dual stack for now.
For instance some repositories have flaky IPv6. Also, within corporations
is still mostly ipv4 and they will want to VPN in and provide services
(e.g., Active Directory) from within their data center.

Another aspect we should keep in mind is security. For example:
Rogue IPv6 RA [http://tools.ietf.org/html/rfc6104]
ND exhaustion [ 
http://blog.ipspace.net/2011/05/ipv6-neighbor-discovery-exhaustion.html]
Unicast RPF [ 
http://www.cisco.com/web/about/security/intelligence/unicast-rpf.html]


On 1/16/14 11:45 PM, "Marcus Sorensen"  wrote:

>Good point. These are the kinds of things we should be aware of right
>now. Even though we don't necessarily want to bite off too much right
>now in initial implementation, we want to plan so that certain things
>we may want to do aren't impossible.
>
>I was thinking either the cloud provider would have a PI, or the end
>user may bring their own to the cloud provider. Either way,
>arrangements need to be made to get it routed up to the point where
>the VPC can service it, and entered as the 'global cidr' for that VPC
>(or at least a small portion of the PI). If we don't, then we have to
>NAT, which as you mentioned isn't really widely supported. I suppose
>nothing would preclude us from allowing a ULA space to be entered as
>the VPC global space later on if we wanted to support NAT for IPv6 on
>the router at some point. You could do either and we'd just route
>public space and NAT/port forward private space.
>
>So, to recap a bit:
>
>VPC is assigned a prefix (say /60). Admin assigns sub-prefix from
>that, per network tier, down to a /64. Route information is published
>both to a plugin framework and the event bus to enable automation of
>upstream route programming (point the /60 to the 'public traffic' ip
>of the VPC router), or admin can manually set up the upstream route
>per VPC.
>
>DNS can be provided by the (currently required) IPv4 recursor on the
>VPC router, but ultimately dnsmasq on IPv6 address can also provide
>it, looking forward to IPv6-only networks.
>
>'public traffic' addressing for VPC routers (the internet-facing
>interface) will be handled by static assignment from a public range,
>much how the IPv4 public traffic is now. This allows for assigning
>extra LB addresses or static NAT addresses in the future.
>
>guest networks, my initial preference would be for SLAAC, but I think
>ultimately we'd want to be able to assign multiple ips to a guest.
>With the 64 bits of the SLAAC space dedicated to all of the unique MAC
>address possibilities, we can't really do that. We may want to
>consider DHCP with static assignments from the beginning.
>
>On Thu, Jan 16, 2014 at 11:32 PM, Chiradeep Vittal
> wrote:
>> Are we assuming that the Cloud Provider has a Provider-Independent (PI)
>> space?
>> Using a Unique Local Address (ULA) space for the VPC *might* to
>>desirable.
>> If VPC tiers (subnets) can span zones (not possible today), then NAT66
>>can
>> help keep addresses stable as workloads move to a different zone for
>> availability reasons.
>> But I see that only Ubuntu has support for NAT66.
>>
>>
>> On 1/16/14 11:33 AM, "Sheng Yang"  wrote:
>>
>>>On Thu, Jan 9, 2014 at 7:04 AM, Daan Hoogland
>>>wrote:
>>>
 H Marcus, We had a small session on how we plan to go about ipv6
 configuration with your bullet list present. Comments are still
 brainstorming phase quality but hopefully they will lead to something.

 > * VPC has no global IPv6 prefix (super CIDR as current private
space),
 it's simply IPv6 enabled or not. Admins can choose to route a /60 or a
/48
 to a vpc and carve it up among the networks there, but it's not
required or
 enforced by cloudstack.
 The idea at Schuberg Philis is that VPCs should have a standard size
 network assigned to be taken from a pool. We should be able to
configure
 the width of the network.  The idea is that per level (Physical
 network/vpc/tier) only one width will be used but the size of it is
 configurable. Default block for a VR / VPC would be a /56 and each
 individual network would use a /64. Note that in a typical isolated
network
 we only use the first.

 > * VPC networks get assigned one or multiple IPv6 prefixes, each
prefix
 can be marked 'SLAAC', 'DHCP', or 'Manual'.
 For networks we are in favor of using SLAAC for configuring routing
and
 addressing, but would advise DHCPv6 to configure DNS and potentially
other
 things (NTP?). No need to register the addresses in CloudStack. We
already
 store the MAC of the NIC so we know which address will be configured
on
the
 interface with the configured prefix. Only the router will receive a
 specific address (p

RE: CS4.1+xenserver 6.1 snapshot error

[Chandan Purushothama]

Hello William,

The XenServer error information " SR_BACKEND_FAILURE_78, , VDI Creation failed 
" implies that the Snaphshot/Volume (XenServer refers to it as VDI - Virtual 
Disk Image) creation on the XenServer failed. The VDI.copy operation copies the 
Volume of the VM as part of Snapshot creation. Looks like something went wrong 
on the XenServer during that phase. You can look for more information on the 
XenServer using the Task record uuid present in the management server log,

On XenServer, Execute the following command,

Xe task-list uuid= 

From the logs, I see that the task record uuid is 
f390af0e-32a9-aea7-c35d-d7aa15c4f163

Thank you,
Chandan. 

-Original Message-
From: William Jiang [mailto:william.ji...@mindgeek.com] 
Sent: Thursday, January 16, 2014 12:02 PM
To: dev@cloudstack.apache.org
Subject: RE: CS4.1+xenserver 6.1 snapshot error

Hello Chandan,
The logs as following, any suggestions?

Great thanks,
William

###
2014-01-16 06:18:14,775 WARN  [xen.resource.CitrixResourceBase] 
(DirectAgent-194:null) Task failed! Task record: uuid: 
f390af0e-32a9-aea7-c35d-d7aa15c4f163
   nameLabel: Async.VDI.copy
 nameDescription:
   allowedOperations: []
   currentOperations: {}
 created: Thu Jan 16 06:18:12 EST 2014
finished: Thu Jan 16 06:18:13 EST 2014
  status: failure
  residentOn: com.xensource.xenapi.Host@112cfb01
progress: 1.0
type: 
  result:
   errorInfo: [SR_BACKEND_FAILURE_78, , VDI Creation failed 
[opterr=error 28]]
 otherConfig: {}
   subtaskOf: com.xensource.xenapi.Task@aaf13f6f
subtasks: []
##



-Original Message-
From: Chandan Purushothama [mailto:chandan.purushoth...@citrix.com]
Sent: January-16-14 2:21 PM
To: dev@cloudstack.apache.org
Subject: RE: CS4.1+xenserver 6.1 snapshot error

Hello Willam,

The logs that you posted doesn’t contain information about why BackupSnapshot 
failed. From the grep information, I can only see the following line in the logs

"The result for com.cloud.agent.api.BackupSnapshotCommand is BackupSnapshot 
Failed due to Task failed! Task record: uuid: 
f390af0e-32a9-aea7-c35d-d7aa15c4f163"

Can you look in the logs for information after this line which might tell you, 
the reason why BackupSnapshot Failed. You will have to change your grep filter,

Thank you,
Chandan.

-Original Message-
From: William Jiang [mailto:william.ji...@mindgeek.com]
Sent: Thursday, January 16, 2014 9:23 AM
To: dev@cloudstack.apache.org
Cc: William Jiang
Subject: CS4.1+xenserver 6.1 snapshot error

Hi Guys,
I have issues of snapshot on some vms, I using cloudstack 4.1 and xenserver 6.1.
The following are the error logs, any ideas or suggestions will be great 
appreciated.
Any other question, if I want clean the error snapshot, how can I achieve it? 
As I try to clean it in Cloudstack management UI, but after refresh, it still 
there.

Great thanks,
William


###Cloudstack management server 
log##
[root@mgt-cld ~]# less /var/log/cloudstack/management/management-server.log 
|grep "Job-Executor-62:job-3754"
2014-01-16 06:16:19,450 DEBUG [cloud.async.AsyncJobManagerImpl] 
(Job-Executor-62:job-3754) Executing 
org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd for job-3754
2014-01-16 06:16:19,455 DEBUG [cloud.user.AccountManagerImpl] 
(Job-Executor-62:job-3754) Access to Acct[5-PrjAcct-Tubes-1] granted to 
Acct[5-PrjAcct-Tubes-1] by DomainChecker_EnhancerByCloudStack_f81f8595
2014-01-16 06:16:19,477 DEBUG [cloud.user.AccountManagerImpl] 
(Job-Executor-62:job-3754) Access to Vol[82|vm=63|DATADISK] granted to 
Acct[5-PrjAcct-Tubes-1] by DomainChecker_EnhancerByCloudStack_f81f8595
2014-01-16 06:16:19,481 DEBUG [storage.snapshot.SnapshotManagerImpl] 
(Job-Executor-62:job-3754) Failed to update snapshot state due to Unable to 
transition to a new state from Creating via CreateRequested
2014-01-16 06:16:19,511 DEBUG [agent.transport.Request] 
(Job-Executor-62:job-3754) Seq 4-823396163: Sending  { Cmd , MgmtId: 
110492071566, via: 4, Ver: v1, Flags: 100011, 
[{"ManageSnapshotCommand":{"_commandSwitch":"-c","_volumePath":"59eb6fcc-6e44-428d-8db5-f602384a4141","_pool":{"id":202,"uuid":"2865ed4f-e8da-31f2-9353-c0abd93d8aba","host":"10.3.34.5","path":"/iqn.2001-05.com.equallogic:0-1cb196-305b0190a-8460019511bd-cloudstackprimary/0","port":3260,"type":"IscsiLUN"},"_snapshotName":"vm111_DATA-63_20140116111619","_snapshotId":1525,"_vmName":"i-5-63-VM","wait":0}}]
 }
2014-01-16 06:16:19,512 DEBUG [agent.transport.Request] 
(Job-Executor-62:jo

Re: IPv6 in VPC (was Re: IPv6 plan - questions)

[Sheng Yang]

On Thu, Jan 16, 2014 at 11:19 PM, Marcus Sorensen wrote:

> On Thu, Jan 16, 2014 at 12:33 PM, Sheng Yang  wrote:
> > On Thu, Jan 9, 2014 at 7:04 AM, Daan Hoogland <
> dhoogl...@schubergphilis.com>
> > wrote:
> >>
> >> H Marcus, We had a small session on how we plan to go about ipv6
> >> configuration with your bullet list present. Comments are still
> >> brainstorming phase quality but hopefully they will lead to something.
> >>
> >> > * VPC has no global IPv6 prefix (super CIDR as current private space),
> >> > it's simply IPv6 enabled or not. Admins can choose to route a /60 or
> a /48
> >> > to a vpc and carve it up among the networks there, but it's not
> required or
> >> > enforced by cloudstack.
> >> The idea at Schuberg Philis is that VPCs should have a standard size
> >> network assigned to be taken from a pool. We should be able to
> configure the
> >> width of the network.  The idea is that per level (Physical
> >> network/vpc/tier) only one width will be used but the size of it is
> >> configurable. Default block for a VR / VPC would be a /56 and each
> >> individual network would use a /64. Note that in a typical isolated
> network
> >> we only use the first.
> >>
> >> > * VPC networks get assigned one or multiple IPv6 prefixes, each prefix
> >> > can be marked 'SLAAC', 'DHCP', or 'Manual'.
> >> For networks we are in favor of using SLAAC for configuring routing and
> >> addressing, but would advise DHCPv6 to configure DNS and potentially
> other
> >> things (NTP?). No need to register the addresses in CloudStack. We
> already
> >> store the MAC of the NIC so we know which address will be configured on
> the
> >> interface with the configured prefix. Only the router will receive a
> >> specific address (prefix::1/64)
> >>
> >> As mentioned earlier first implementation will do SLAAC. How will SLAAC
> be
> >> configured with ACL's?
> >>
> >> > * Mgmt server allows calling external plugins for pushing routes to
> >> > routers upstream of VPCs (SDN or router API), but could be manually
> done by
> >> > admins as well
> >> We discussed the routing issues in front of the VPC / VR. The goal is to
> >> provide cloudstack with a way to deal with routable addresses inside an
> >> isolated network, as actually this problem is relevant for both IPv4 and
> >> IPv6. However for IPv4 we have a perfectly workable solution with NAT
> and in
> >> the IPv6 world we don't/. So we need to address this issue on how to
> route a
> >> network from the provider edge into an isolated network.
> >>
> >> For IPv6 we have several options:
> >> *   Dynamic routing protocols, here we can think of iBGP, OSPF or
> any
> >> other protocol. Basically cloudstack assigns a block to a VR / VPC and
> the
> >> VPC / VR tells the outside world to route that block to the outside IP
> of
> >> the router.
> >> *   Block allocator, cloudstack knows about the supernet (/48 for
> >> example) and assigns a block (/56) to a VR or VPC. Cloudstack tells the
> >> block allocator to allocate (route) this block to the VR/VPC. Block
> >> allocater needs to know about the device being managed (upstream router
> like
> >> cisco/juniper) and configured the route using telnet or an API
> >> *   Broker, We introduce a new systemvm, the block broker. The admin
> >> routes the /48 to the block broker and CloudStack tells the blok broker
> to
> >> reroute a specific subblock to this VR / VPC
> >> *   Static, Admin configures a list of block/ip pairs in the
> upstream
> >> router. CloudStack knows about these pairs and assigns the ip to the VR
> /
> >> VPC and the block will be routed.
> >>
> >>
> >> > * Work could be done in stages, e.g. SLAAC/manual network ranges would
> >> > be fairly straightforward, whereas DHCP ranges would require
> programming
> >> > scripts and ip allocation code.
> >>
> >> > * An issue was raised about privacy concerns with SLAAC using MAC, but
> >> > we think this revolves more around clients than servers; that is, a
> client
> >> > moving around the country would be traceable because of the MAC, but a
> >> > server always has the same address anyway.
> >>
> >> > * Still need to figure out what to do about ACLs, that's a whole
> >> > separate issue, but a plan needs to be in place.
> >> Are we going to put ACL's on networks or hosts or both? What is easiest
> to
> >> implement and enforce?
> >
> >
> > The routing is controlled by upstream router, so it's straightforward
> that
> > ACL would be done by upstream router.
>
> I think we're talking about ACLs as in the way ACLs are currently
> implemented in VPC. The VPC router would block, for example, traffic
> from it's public interface into a specific tier, via a rule that
> Cloudstack manages. Also, we're easily in control here, whereas it's
> difficult to do upstream.
>

Um, yes, I forgot the VPC router would still control the traffic for
network, through router advertisement. Then it would be easily done as
today.

--Sheng

>
> >
> > But after rethink, modifyin

RE: systemvm templates

[Alex Huang]

Why is jre7 required for vmware?  Kelven, you have any idea?

--Alex

> -Original Message-
> From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
> Sent: Friday, January 17, 2014 9:08 AM
> To: dev@cloudstack.apache.org
> Subject: Re: systemvm templates
> 
> Hugo,
> 
>   First of all my bad that I jumped the gun on jre7 change. I will be testing 
> the
> full build on master and then update the urls and other changes.
> In the current template jre7 package is not available by default, needs apt-
> get update. jre7 is a absolute necessity for VMWare template.
> 
> Once I have a successful local build I will update the thread.
> 
> -abhi
> 
> 
> On 17/01/14 10:20 pm, "Hugo Trippaers"  wrote:
> 
> >Abhi,
> >
> >I have the debian 7.0.0 isis local on the jenkins server, so we don¹t
> >depend on the external URLs.
> >
> >Do you want to switch master to the new image? No trouble for me to
> >make it happen.
> >
> >Cheers,
> >
> >Hugo
> >
> >On 17 jan. 2014, at 17:12, Abhinandan Prateek
> > wrote:
> >
> >>
> >> While trying to build systemvm templates I noticed that the urls to
> >>download the debian images are invalid as in definition.rb in
> >>respective
> >>folders:
> >>
> >> For 64 bit template
> >>http://cdimage.debian.org/mirror/cdimage/archive/7.0.0/i386/iso-cd/deb
> >>ian
> >>-7.0.0-i386-netinst.iso
> >> For 32 bit template
> >>http://cdimage.debian.org/mirror/cdimage/archive/7.0.0/i386/iso-cd/deb
> >>ian
> >>-7.0.0-i386-netinst.iso
> >>
> >> I will be updating these to following respectively, once I have a
> >>successful local build:
> >>
> >>
> >>http://ftp.acc.umu.se/mirror/cdimage/release/7.3.0/i386/iso-cd/debian-
> 7.3
> >>.0-i386-netinst.iso   MD5: 04c58f30744e64a0459caf7d7cace479
> >>
> >>http://ftp.acc.umu.se/mirror/cdimage/release/7.3.0/ia64/iso-cd/debian-
> >>7.3 .0-ia64-netinst.iso  MD5: a6b93666a5393334accb7ac4ee28d949
> >>
> >> Not sure if jenkins job is building the right templates now ?
> >>
> >> -abhi
> >>
> >>
> >>
> >

Re: UI blocker

[Sebastien Goasguen]

On Jan 17, 2014, at 1:41 PM, Brian Federle  wrote:

> Sorry, but cosmetic issues are not blockers :) It would only be a blockers if 
> the functionality were NOT usable in any shape or form, for both testing and 
> end use.
> 

I disagree, cosmetics i.e look and feel of a new major revision of a software 
are as important as critical backend features. Because users will look at it, 
managers, execs…etc, it will be displayed in demos, printed on booths 
etc….anything that does not look top notch reflects badly on the project and 
the software.


> i.e. -- if the fields were completely missing or garbled in some way, I would 
> agree that we can classify the bug as blocking release. Looking 'ugly', no -- 
> I implemented the scrollbars because most times API keys, etc. are usually 
> very long strings, causing overflow on some browsers and in most usability 
> cases people are mainly needing to just copy/paste the values into other 
> fields. It's not the most elegant solution I understand, but this is also a 
> small facet of the whole UI experience.
> 

Attention to details is important. Personally the new UI is distracting to me, 
the variation in fonts/font sizes is distracting instead of putting emphasis 
and focus. There are other things, like 'ovm' still showing up in the add 
cluster drop down when OVM is not supported in CloudStack, but you are right 
it's a detail who cares.

> I am going to ask everyone to PLEASE respect this when determining priority 
> on UI bugs -- I know things like this are somewhat ugly, but there are only a 
> small handful of full-time UI developers working on CloudStack and it makes 
> our lives harder if everyone is marking trivial stuff as show-stoppers.
> 

This is great, so it can look like crap, as long as it works we release on the 
first iteration of a major revision. In any case you can remove this as a 
blocker, it seems I am in minority here, at least I got you to respond on the 
list and share your thoughts on the subject. As a parting thought though, I 
don't think that 'everyone is making trivial stuff as show-stoppers', I did not 
hear many UI blocker bugs lately

> At any rate, if you still think this is a blocker, you can feel free to look 
> into it yourself, in which case write a review request and I'll take a look 
> at it.

> 
> -Brian
> 
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com] 
> Sent: Thursday, January 16, 2014 11:56 AM
> To: Brian Federle
> Cc: dev@cloudstack.apache.org; Jessica Wang
> Subject: Re: UI blocker
> 
> 
> On Jan 16, 2014, at 2:48 PM, Brian Federle  wrote:
> 
 Did you happen to check the View Users page ? the api/secret keys display 
 is being truncated.
>> 
>> Yes, though to fix that I'll have to rework a bit of the detail view layout 
>> to allow more flexible sizing for long strings. File that as a separate bug 
>> for the next release and I'll take a look at it.
> 
> No, I will keep that as a blocker. it's worse than the previous UI, feel free 
> to comment in the bug and grab it.
> 
>> 
>> -Original Message-
>> From: Sebastien Goasguen [mailto:run...@gmail.com] 
>> Sent: Thursday, January 16, 2014 11:17 AM
>> To: Brian Federle
>> Cc: dev@cloudstack.apache.org; Jessica Wang
>> Subject: Re: UI blocker
>> 
>> 
>> On Jan 16, 2014, at 1:39 PM, Brian Federle  wrote:
>> 
>>> Don't see any issues in the screenshot you posted. The variation in font 
>>> size and weight, color, etc. are used to show contrast between content and 
>>> titles. Sorry but I do not see this as a blocker issue :) Though feel free 
>>> to tweak the fonts yourself.
>>> 
>> 
>> It looks strange to me, maybe that's just me. I see too many variations and 
>> it's disturbing.
>> 
>> Did you happen to check the View Users page ? the api/secret keys display is 
>> being truncated. 
>> 
>>> -Brian
>>> 
>>> -Original Message-
>>> From: sebgoa [mailto:run...@gmail.com] 
>>> Sent: Thursday, January 16, 2014 1:43 AM
>>> To: dev@cloudstack.apache.org
>>> Cc: Jessica Wang; Brian Federle
>>> Subject: UI blocker
>>> 
>>> Hi, after testing 4.3 I entered a blocker due to UI issues:
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-5882
>>> 
>>> It would be good to discuss, 
>>> 
>>> thanks,
>>> 
>>> -Sebastien
>> 
> 

RE: UI blocker

[Brian Federle]

OK, I'm dropping this subject after this, but one more thing -- the new UI has 
been up for months now. There was plenty of time to make feedback and improve 
the UI. I don't appreciate the fact that these issues are being mentioned so 
late into release, when there isn't much we can do about it. Also, we are 
working on other deliverables for future releases, so the fact that our bug 
count is low for 4.3 doesn't mean we aren't doing any work :)

-Original Message-
From: Sebastien Goasguen [mailto:run...@gmail.com] 
Sent: Friday, January 17, 2014 11:53 AM
To: dev@cloudstack.apache.org; Brian Federle
Cc: Jessica Wang; Sonny Chhen
Subject: Re: UI blocker


On Jan 17, 2014, at 1:41 PM, Brian Federle  wrote:

> Sorry, but cosmetic issues are not blockers :) It would only be a blockers if 
> the functionality were NOT usable in any shape or form, for both testing and 
> end use.
> 

I disagree, cosmetics i.e look and feel of a new major revision of a software 
are as important as critical backend features. Because users will look at it, 
managers, execs...etc, it will be displayed in demos, printed on booths 
etcanything that does not look top notch reflects badly on the project and 
the software.


> i.e. -- if the fields were completely missing or garbled in some way, I would 
> agree that we can classify the bug as blocking release. Looking 'ugly', no -- 
> I implemented the scrollbars because most times API keys, etc. are usually 
> very long strings, causing overflow on some browsers and in most usability 
> cases people are mainly needing to just copy/paste the values into other 
> fields. It's not the most elegant solution I understand, but this is also a 
> small facet of the whole UI experience.
> 

Attention to details is important. Personally the new UI is distracting to me, 
the variation in fonts/font sizes is distracting instead of putting emphasis 
and focus. There are other things, like 'ovm' still showing up in the add 
cluster drop down when OVM is not supported in CloudStack, but you are right 
it's a detail who cares.

> I am going to ask everyone to PLEASE respect this when determining priority 
> on UI bugs -- I know things like this are somewhat ugly, but there are only a 
> small handful of full-time UI developers working on CloudStack and it makes 
> our lives harder if everyone is marking trivial stuff as show-stoppers.
> 

This is great, so it can look like crap, as long as it works we release on the 
first iteration of a major revision. In any case you can remove this as a 
blocker, it seems I am in minority here, at least I got you to respond on the 
list and share your thoughts on the subject. As a parting thought though, I 
don't think that 'everyone is making trivial stuff as show-stoppers', I did not 
hear many UI blocker bugs lately

> At any rate, if you still think this is a blocker, you can feel free to look 
> into it yourself, in which case write a review request and I'll take a look 
> at it.

> 
> -Brian
> 
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com] 
> Sent: Thursday, January 16, 2014 11:56 AM
> To: Brian Federle
> Cc: dev@cloudstack.apache.org; Jessica Wang
> Subject: Re: UI blocker
> 
> 
> On Jan 16, 2014, at 2:48 PM, Brian Federle  wrote:
> 
 Did you happen to check the View Users page ? the api/secret keys display 
 is being truncated.
>> 
>> Yes, though to fix that I'll have to rework a bit of the detail view layout 
>> to allow more flexible sizing for long strings. File that as a separate bug 
>> for the next release and I'll take a look at it.
> 
> No, I will keep that as a blocker. it's worse than the previous UI, feel free 
> to comment in the bug and grab it.
> 
>> 
>> -Original Message-
>> From: Sebastien Goasguen [mailto:run...@gmail.com] 
>> Sent: Thursday, January 16, 2014 11:17 AM
>> To: Brian Federle
>> Cc: dev@cloudstack.apache.org; Jessica Wang
>> Subject: Re: UI blocker
>> 
>> 
>> On Jan 16, 2014, at 1:39 PM, Brian Federle  wrote:
>> 
>>> Don't see any issues in the screenshot you posted. The variation in font 
>>> size and weight, color, etc. are used to show contrast between content and 
>>> titles. Sorry but I do not see this as a blocker issue :) Though feel free 
>>> to tweak the fonts yourself.
>>> 
>> 
>> It looks strange to me, maybe that's just me. I see too many variations and 
>> it's disturbing.
>> 
>> Did you happen to check the View Users page ? the api/secret keys display is 
>> being truncated. 
>> 
>>> -Brian
>>> 
>>> -Original Message-
>>> From: sebgoa [mailto:run...@gmail.com] 
>>> Sent: Thursday, January 16, 2014 1:43 AM
>>> To: dev@cloudstack.apache.org
>>> Cc: Jessica Wang; Brian Federle
>>> Subject: UI blocker
>>> 
>>> Hi, after testing 4.3 I entered a blocker due to UI issues:
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-5882
>>> 
>>> It would be good to discuss, 
>>> 
>>> thanks,
>>> 
>>> -Sebastien
>> 
> 

RE: UI blocker

[Alex Hitchins]

I do understand your thoughts on the importance of the issue. The initial 
impact is very important and a confusing UI can easily turn away potential 
adopters. That said I wouldn't have a UI issue as a blocker unless it prevented 
normal use (like not being able to enter text or see labels off screen).

I believe we have shipped with known issues before, I think it would be 
acceptable to release with the CSS issue as a note.


Alex Hitchins
+44 7788 423 969

-Original Message-
From: Sebastien Goasguen [mailto:run...@gmail.com]
Sent: 17 January 2014 19:53
To: dev@cloudstack.apache.org; Brian Federle
Cc: Jessica Wang; Sonny Chhen
Subject: Re: UI blocker


On Jan 17, 2014, at 1:41 PM, Brian Federle  wrote:

> Sorry, but cosmetic issues are not blockers :) It would only be a blockers if 
> the functionality were NOT usable in any shape or form, for both testing and 
> end use.
>

I disagree, cosmetics i.e look and feel of a new major revision of a software 
are as important as critical backend features. Because users will look at it, 
managers, execs...etc, it will be displayed in demos, printed on booths 
etcanything that does not look top notch reflects badly on the project and 
the software.


> i.e. -- if the fields were completely missing or garbled in some way, I would 
> agree that we can classify the bug as blocking release. Looking 'ugly', no -- 
> I implemented the scrollbars because most times API keys, etc. are usually 
> very long strings, causing overflow on some browsers and in most usability 
> cases people are mainly needing to just copy/paste the values into other 
> fields. It's not the most elegant solution I understand, but this is also a 
> small facet of the whole UI experience.
>

Attention to details is important. Personally the new UI is distracting to me, 
the variation in fonts/font sizes is distracting instead of putting emphasis 
and focus. There are other things, like 'ovm' still showing up in the add 
cluster drop down when OVM is not supported in CloudStack, but you are right 
it's a detail who cares.

> I am going to ask everyone to PLEASE respect this when determining priority 
> on UI bugs -- I know things like this are somewhat ugly, but there are only a 
> small handful of full-time UI developers working on CloudStack and it makes 
> our lives harder if everyone is marking trivial stuff as show-stoppers.
>

This is great, so it can look like crap, as long as it works we release on the 
first iteration of a major revision. In any case you can remove this as a 
blocker, it seems I am in minority here, at least I got you to respond on the 
list and share your thoughts on the subject. As a parting thought though, I 
don't think that 'everyone is making trivial stuff as show-stoppers', I did not 
hear many UI blocker bugs lately

> At any rate, if you still think this is a blocker, you can feel free to look 
> into it yourself, in which case write a review request and I'll take a look 
> at it.

>
> -Brian
>
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: Thursday, January 16, 2014 11:56 AM
> To: Brian Federle
> Cc: dev@cloudstack.apache.org; Jessica Wang
> Subject: Re: UI blocker
>
>
> On Jan 16, 2014, at 2:48 PM, Brian Federle  wrote:
>
 Did you happen to check the View Users page ? the api/secret keys display 
 is being truncated.
>>
>> Yes, though to fix that I'll have to rework a bit of the detail view layout 
>> to allow more flexible sizing for long strings. File that as a separate bug 
>> for the next release and I'll take a look at it.
>
> No, I will keep that as a blocker. it's worse than the previous UI, feel free 
> to comment in the bug and grab it.
>
>>
>> -Original Message-
>> From: Sebastien Goasguen [mailto:run...@gmail.com]
>> Sent: Thursday, January 16, 2014 11:17 AM
>> To: Brian Federle
>> Cc: dev@cloudstack.apache.org; Jessica Wang
>> Subject: Re: UI blocker
>>
>>
>> On Jan 16, 2014, at 1:39 PM, Brian Federle  wrote:
>>
>>> Don't see any issues in the screenshot you posted. The variation in font 
>>> size and weight, color, etc. are used to show contrast between content and 
>>> titles. Sorry but I do not see this as a blocker issue :) Though feel free 
>>> to tweak the fonts yourself.
>>>
>>
>> It looks strange to me, maybe that's just me. I see too many variations and 
>> it's disturbing.
>>
>> Did you happen to check the View Users page ? the api/secret keys display is 
>> being truncated.
>>
>>> -Brian
>>>
>>> -Original Message-
>>> From: sebgoa [mailto:run...@gmail.com]
>>> Sent: Thursday, January 16, 2014 1:43 AM
>>> To: dev@cloudstack.apache.org
>>> Cc: Jessica Wang; Brian Federle
>>> Subject: UI blocker
>>>
>>> Hi, after testing 4.3 I entered a blocker due to UI issues:
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-5882
>>>
>>> It would be good to discuss,
>>>
>>> thanks,
>>>
>>> -Sebastien
>>
>

Need Enterprise Grade Support for Apache CloudStack?
Our CloudStack 

Build failed in Jenkins: cloudstack-4.3-maven-build #431

[jenkins]

See 

Changes:

[anthony.xu] only send stop command when agent reports VM running and CS thinks 
it is stopped.

[jessicawang] CLOUDSTACK-5656: UI > Network > IP Address > configuration tab > 
Load Balancing > add "State" column.

[jessicawang] CLOUDSTACK-5656: UI > Network > IP Address > configuration tab > 
Firewall > add "State" column.

--
[...truncated 950 lines...]
[INFO] Surefire report directory: 


---
 T E S T S
---

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO] 
[INFO] Building Apache CloudStack Server 4.3.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cloud-server ---
[INFO] Deleting 
 
(includes = [target, dist], excludes = [])
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.3:process (default) @ cloud-server 
---
[INFO] 
[INFO] --- maven-antrun-plugin:1.7:run (generate-resource) @ cloud-server ---
[INFO] Executing tasks

main:
 [copy] Copying 3 files to 

 [copy] Copying 1 file to 

[INFO] Executed tasks
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-server ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 30 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ cloud-server 
---
[INFO] Compiling 358 source files to 

[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-server ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 29 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-server ---
[INFO] Compiling 75 source files to 

[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ cloud-server ---
[INFO] Surefire report directory: 


---
 T E S T S
---
Running com.cloud.event.EventControlsUnitTest
log4j:WARN No appenders could be found for logger 
(com.cloud.event.EventControlsUnitTest).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
info.
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.505 sec
Running com.cloud.keystore.KeystoreTest
org.apache.cloudstack.api.response.UserVmResponse/null/{"id":"3","securitygroup":[],"nic":[],"tags":[],"affinitygroup":[]}
org.apache.cloudstack.api.response.AlertResponse/null/{"id":"100","description":"Hello"}
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.34 sec
Running com.cloud.alert.AlertControlsUnitTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.081 sec
Running com.cloud.capacity.CapacityManagerTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.377 sec
Running com.cloud.resourcelimit.ResourceLimitManagerImplTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running com.cloud.network.firewall.FirewallManagerTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.002 sec
Running com.cloud.network.UpdatePhysicalNetworkTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.495 sec
Running com.cloud.network.CreatePrivateNetworkTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.301 sec
Running com.cloud.network.NetworkModelTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.285 sec
Running com.cloud.network.security.SecurityGroupManagerImplTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.238 sec
Running com.cloud.network.security.SecurityGroupQueueTest
Num Vms= 50 Queue size = 50
Num Vms= 2 Queue size = 2 time=4273 ms
Num Vms= 5000 Queue size = 5000 time=3619 ms
Num Vms= 1 Queue size = 1 time=1 ms
Num Vms= 1

Cannot delete ISO

[Francois Gaudreault]

We have a fresh 4.2.1 install, and apparently we cannot delete ISO that 
failed to download? We are using XenServer hypervisors.


2014-01-17 16:06:41,833 INFO [cloud.template.HypervisorTemplateAdapter] 
(Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ]) 
Delete template from image store: Prod-SecStor
2014-01-17 16:06:41,836 DEBUG [storage.image.TemplateDataFactoryImpl] 
(Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ]) 
template 203 is already in store:1, type:Image
2014-01-17 16:06:41,956 DEBUG [agent.transport.Request] 
(Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ]) Seq 
5-2088570903: Sending  { Cmd , MgmtId: 99433950741773, via: 5, Ver: v1, 
Flags: 100011, 
[{"org.apache.cloudstack.storage.command.DeleteCommand":{"data":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/5/203","origUrl":"http://cloudstack.ixxx.com/iso/WinServer_2008_R2_x64_ENG.ISO","uuid":"94e4ee85-c1af-4eac-b695-d5912a6c9c41","id":203,"format":"ISO","accountId":5,"hvm":true,"displayText":"Test 
2nd","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.100.x.xxx/data/prod_zone","_role":"Image"}},"name":"203-5-7cca35bd-0eaa-37fe-a45a-418bcc5d9b96","hypervisorType":"None"}},"wait":0}}] 
}
2014-01-17 16:06:42,054 DEBUG [agent.transport.Request] 
(AgentManager-Handler-6:null) Seq 5-2088570903: Processing:  { Ans: , 
MgmtId: 99433950741773, via: 5, Ver: v1, Flags: 10, 
[{"com.cloud.agent.api.Answer":{"result":false,"details":"Unable to 
delete file 204 under Template path template/tmpl/5/203","wait":0}}] }
2014-01-17 16:06:42,054 DEBUG [agent.transport.Request] 
(Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ]) Seq 
5-2088570903: Received:  { Ans: , MgmtId: 99433950741773, via: 5, Ver: 
v1, Flags: 10, { Answer } }
2014-01-17 16:06:42,125 WARN [cloud.template.HypervisorTemplateAdapter] 
(Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ]) 
Failed to delete the template 
Tmpl[203-ISO-203-5-7cca35bd-0eaa-37fe-a45a-418bcc5d9b96 from the image 
store: Prod-SecStor due to: Unable to delete file 204 under Template 
path template/tmpl/5/203
2014-01-17 16:06:42,206 ERROR [cloud.async.AsyncJobManagerImpl] 
(Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ]) 
Unexpected exception while executing 
org.apache.cloudstack.api.command.user.iso.DeleteIsoCmd

com.cloud.utils.exception.CloudRuntimeException: Failed to delete ISO
at 
com.cloud.template.TemplateManagerImpl.deleteIso(TemplateManagerImpl.java:1120)
at 
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
at 
org.apache.cloudstack.api.command.user.iso.DeleteIsoCmd.execute(DeleteIsoCmd.java:110)

at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
at 
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)

at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:701)

--
Francois Gaudreault
Architecte de Solution Cloud | Cloud Solutions Architect
fgaudrea...@cloudops.com
514-629-6775
- - -
CloudOps
420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_

Re: IPv6 in VPC (was Re: IPv6 plan - questions)

[Marcus Sorensen]

On Fri, Jan 17, 2014 at 11:59 AM, Chiradeep Vittal
 wrote:
> Yes, let's not shut out the ULA option.
>
> For the LB "Public" interface, will this be just another tier? That is,
> not an explicit public VLAN.

Well, we do have the internal LB function, but I was thinking more
along the lines of what we have now with IPv4, that is, there's a
public network that all IPv4 VPCs are already attaching to, we just
need to drop an IPv6 range on that so that VPCs can grab addresses for
themselves and any routing/LB/NAT66 they may want to do.

>
> Since IPV6 support is still sparse, it is probably best that we support
> dual stack for now.
> For instance some repositories have flaky IPv6. Also, within corporations
> is still mostly ipv4 and they will want to VPN in and provide services
> (e.g., Active Directory) from within their data center.
>
> Another aspect we should keep in mind is security. For example:
> Rogue IPv6 RA [http://tools.ietf.org/html/rfc6104]
> ND exhaustion [
> http://blog.ipspace.net/2011/05/ipv6-neighbor-discovery-exhaustion.html]
> Unicast RPF [
> http://www.cisco.com/web/about/security/intelligence/unicast-rpf.html]
>
>
> On 1/16/14 11:45 PM, "Marcus Sorensen"  wrote:
>
>>Good point. These are the kinds of things we should be aware of right
>>now. Even though we don't necessarily want to bite off too much right
>>now in initial implementation, we want to plan so that certain things
>>we may want to do aren't impossible.
>>
>>I was thinking either the cloud provider would have a PI, or the end
>>user may bring their own to the cloud provider. Either way,
>>arrangements need to be made to get it routed up to the point where
>>the VPC can service it, and entered as the 'global cidr' for that VPC
>>(or at least a small portion of the PI). If we don't, then we have to
>>NAT, which as you mentioned isn't really widely supported. I suppose
>>nothing would preclude us from allowing a ULA space to be entered as
>>the VPC global space later on if we wanted to support NAT for IPv6 on
>>the router at some point. You could do either and we'd just route
>>public space and NAT/port forward private space.
>>
>>So, to recap a bit:
>>
>>VPC is assigned a prefix (say /60). Admin assigns sub-prefix from
>>that, per network tier, down to a /64. Route information is published
>>both to a plugin framework and the event bus to enable automation of
>>upstream route programming (point the /60 to the 'public traffic' ip
>>of the VPC router), or admin can manually set up the upstream route
>>per VPC.
>>
>>DNS can be provided by the (currently required) IPv4 recursor on the
>>VPC router, but ultimately dnsmasq on IPv6 address can also provide
>>it, looking forward to IPv6-only networks.
>>
>>'public traffic' addressing for VPC routers (the internet-facing
>>interface) will be handled by static assignment from a public range,
>>much how the IPv4 public traffic is now. This allows for assigning
>>extra LB addresses or static NAT addresses in the future.
>>
>>guest networks, my initial preference would be for SLAAC, but I think
>>ultimately we'd want to be able to assign multiple ips to a guest.
>>With the 64 bits of the SLAAC space dedicated to all of the unique MAC
>>address possibilities, we can't really do that. We may want to
>>consider DHCP with static assignments from the beginning.
>>
>>On Thu, Jan 16, 2014 at 11:32 PM, Chiradeep Vittal
>> wrote:
>>> Are we assuming that the Cloud Provider has a Provider-Independent (PI)
>>> space?
>>> Using a Unique Local Address (ULA) space for the VPC *might* to
>>>desirable.
>>> If VPC tiers (subnets) can span zones (not possible today), then NAT66
>>>can
>>> help keep addresses stable as workloads move to a different zone for
>>> availability reasons.
>>> But I see that only Ubuntu has support for NAT66.
>>>
>>>
>>> On 1/16/14 11:33 AM, "Sheng Yang"  wrote:
>>>
On Thu, Jan 9, 2014 at 7:04 AM, Daan Hoogland
wrote:

> H Marcus, We had a small session on how we plan to go about ipv6
> configuration with your bullet list present. Comments are still
> brainstorming phase quality but hopefully they will lead to something.
>
> > * VPC has no global IPv6 prefix (super CIDR as current private
>space),
> it's simply IPv6 enabled or not. Admins can choose to route a /60 or a
>/48
> to a vpc and carve it up among the networks there, but it's not
>required or
> enforced by cloudstack.
> The idea at Schuberg Philis is that VPCs should have a standard size
> network assigned to be taken from a pool. We should be able to
>configure
> the width of the network.  The idea is that per level (Physical
> network/vpc/tier) only one width will be used but the size of it is
> configurable. Default block for a VR / VPC would be a /56 and each
> individual network would use a /64. Note that in a typical isolated
>network
> we only use the first.
>
> > * VPC networks get assigned one or multiple IPv6 prefixe

Build failed in Jenkins: build-master-noredist #2126

[jenkins]

See 

Changes:

[anthony.xu] only send stop command when agent reports VM running and CS thinks 
it is stopped.

[jessicawang] CLOUDSTACK-5656: UI > Network > IP Address > configuration tab > 
Load Balancing > add "State" column.

[kelveny] CLOUDSTACK-5731: Use general instance type to categorize VM work jobs 
to correctly serialize VM operations

[jessicawang] CLOUDSTACK-5656: UI > Network > IP Address > configuration tab > 
Firewall > add "State" column.

[sheng.yang] CLOUDSTACK-5779: Move ipAlias to use routerProxy

[sheng.yang] CLOUDSTACK-5779: Move firewall to use routerProxy

[sheng.yang] CLOUDSTACK-5779: Clean up savepassword scripts

--
[...truncated  lines...]
[INFO] 
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
cloud-quickcloud ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-quickcloud ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ cloud-quickcloud ---
[INFO] Surefire report directory: 


---
 T E S T S
---

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ cloud-quickcloud ---
[INFO] Building jar: 

[INFO] 
[INFO] --- maven-site-plugin:3.1:attach-descriptor (attach-descriptor) @ 
cloud-quickcloud ---
[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ 
cloud-quickcloud ---
[INFO] Installing 

 to 
/jenkins/.m2/repository/org/apache/cloudstack/cloud-quickcloud/4.4.0-SNAPSHOT/cloud-quickcloud-4.4.0-SNAPSHOT.jar
[INFO] Installing 

 to 
/jenkins/.m2/repository/org/apache/cloudstack/cloud-quickcloud/4.4.0-SNAPSHOT/cloud-quickcloud-4.4.0-SNAPSHOT.pom
[INFO] 
[INFO] 
[INFO] Building Apache CloudStack AWS API Bridge 4.4.0-SNAPSHOT
[INFO] 
[WARNING] The POM for org.apache.rampart:rampart-policy:jar:1.5.1 is invalid, 
transitive dependencies (if any) will not be available, enable debug logging 
for more details
[WARNING] The POM for org.apache.rampart:rampart-trust:jar:1.5.1 is invalid, 
transitive dependencies (if any) will not be available, enable debug logging 
for more details
[WARNING] The POM for org.apache.axis2:axis2-kernel:jar:1.5.4 is invalid, 
transitive dependencies (if any) will not be available, enable debug logging 
for more details
[WARNING] The POM for org.apache.axis2:mex:jar:impl:1.5.4 is invalid, 
transitive dependencies (if any) will not be available, enable debug logging 
for more details
[WARNING] The POM for org.apache.axis2:axis2-mtompolicy:jar:1.5.4 is invalid, 
transitive dependencies (if any) will not be available, enable debug logging 
for more details
[WARNING] The POM for org.apache.axis2:addressing:mar:1.5.4 is invalid, 
transitive dependencies (if any) will not be available, enable debug logging 
for more details
[WARNING] The POM for org.apache.ws.commons.axiom:axiom-dom:jar:1.2.10 is 
invalid, transitive dependencies (if any) will not be available, enable debug 
logging for more details
[WARNING] The POM for org.apache.ws.security:wss4j:jar:1.5.10 is invalid, 
transitive dependencies (if any) will not be available, enable debug logging 
for more details
[WARNING] The POM for org.apache.santuario:xmlsec:jar:1.4.2 is invalid, 
transitive dependencies (if any) will not be available, enable debug logging 
for more details
[WARNING] The POM for org.opensaml:opensaml1:jar:1.1 is invalid, transitive 
dependencies (if any) will not be available, enable debug logging for more 
details
[WARNING] The POM for org.slf4j:slf4j-jdk

Re: systemvm templates

[Abhinandan Prateek]

In SSVM for VMWare, copying template to primary storage fails in some
cases with jre 6. 

-abhi

On 18/01/14 1:08 am, "Alex Huang"  wrote:

>Why is jre7 required for vmware?  Kelven, you have any idea?
>
>--Alex
>
>> -Original Message-
>> From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
>> Sent: Friday, January 17, 2014 9:08 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: systemvm templates
>> 
>> Hugo,
>> 
>>   First of all my bad that I jumped the gun on jre7 change. I will be
>>testing the
>> full build on master and then update the urls and other changes.
>> In the current template jre7 package is not available by default, needs
>>apt-
>> get update. jre7 is a absolute necessity for VMWare template.
>> 
>> Once I have a successful local build I will update the thread.
>> 
>> -abhi
>> 
>> 
>> On 17/01/14 10:20 pm, "Hugo Trippaers"  wrote:
>> 
>> >Abhi,
>> >
>> >I have the debian 7.0.0 isis local on the jenkins server, so we don¹t
>> >depend on the external URLs.
>> >
>> >Do you want to switch master to the new image? No trouble for me to
>> >make it happen.
>> >
>> >Cheers,
>> >
>> >Hugo
>> >
>> >On 17 jan. 2014, at 17:12, Abhinandan Prateek
>> > wrote:
>> >
>> >>
>> >> While trying to build systemvm templates I noticed that the urls to
>> >>download the debian images are invalid as in definition.rb in
>> >>respective
>> >>folders:
>> >>
>> >> For 64 bit template
>> >>http://cdimage.debian.org/mirror/cdimage/archive/7.0.0/i386/iso-cd/deb
>> >>ian
>> >>-7.0.0-i386-netinst.iso
>> >> For 32 bit template
>> >>http://cdimage.debian.org/mirror/cdimage/archive/7.0.0/i386/iso-cd/deb
>> >>ian
>> >>-7.0.0-i386-netinst.iso
>> >>
>> >> I will be updating these to following respectively, once I have a
>> >>successful local build:
>> >>
>> >>
>> >>http://ftp.acc.umu.se/mirror/cdimage/release/7.3.0/i386/iso-cd/debian-
>> 7.3
>> >>.0-i386-netinst.iso   MD5: 04c58f30744e64a0459caf7d7cace479
>> >>
>> >>http://ftp.acc.umu.se/mirror/cdimage/release/7.3.0/ia64/iso-cd/debian-
>> >>7.3 .0-ia64-netinst.iso  MD5: a6b93666a5393334accb7ac4ee28d949
>> >>
>> >> Not sure if jenkins job is building the right templates now ?
>> >>
>> >> -abhi
>> >>
>> >>
>> >>
>> >
>

4.3 BVT automation result on Xen

[Rayees Namathponnan]

Hi All,

Here 4.3 BVT automation result on Xen, 
http://jenkins.buildacloud.org/view/cloudstack-qa/job/test-smoke-matrix/1140/testReport/

There are ,many failures observed with this run;  failures are due to 
https://issues.apache.org/jira/browse/CLOUDSTACK-5898

This issue is fixed by Anthony now,  I will start another run now

name
  passfailskip
test_templates/
7   01
test_network_acl/ 1 
  0   0
test_portable_publicip/ 2   
0   0
test_disk_offerings/  3 
  0   0
test_deploy_vm/   1 
  0   0
test_deploy_vms_with_varied_deploymentplanners/  3   0   0
test_vm_snapshots/  3   
0   0
test_nic/   
1   0   0
test_reset_vm_on_reboot/1   
0   0
test_network/   
6   2   0
test_vm_life_cycle/  10 
  0   0
test_pvlan/ 
  1   0   0
test_global_settings/1  
 0   0
test_multipleips_per_nic/  1
   0   0
test_regions/   
 1   0   0
test_scale_vm/  
1   0   0
test_loadbalance/  
0   3   0
test_resource_detail/ 1 
  0   0
test_deploy_vm_with_userdata/ 2   0 
  0
test_privategw_acl/   1 
  0   0
test_public_ip_range/1  
 0   0
test_service_offerings/  3  
 1   0
test_non_contigiousvlan/  1 
  0   0
test_volumes/   
9   0   0
test_affinity_groups/ 1 
  0   0
test_routers/   
  8   1   0
test_iso/   
1   1   0
test_vpc_vpn/   
2   0   0
test_internal_lb/   
1   0   0
test_ssvm/  
  9   1   0
test_guest_vlan_range/ 1
   0   0


Regards,
Rayees

Jenkins build is back to normal : cloudstack-4.3-maven-build #432

[jenkins]

See 

Re: Cannot delete ISO

[Min Chen]

This is a bug in deleting an ISO that is not successfully downloaded.

Thanks
-min

On 1/17/14 1:12 PM, "Francois Gaudreault"  wrote:

>We have a fresh 4.2.1 install, and apparently we cannot delete ISO that
>failed to download? We are using XenServer hypervisors.
>
>2014-01-17 16:06:41,833 INFO [cloud.template.HypervisorTemplateAdapter]
>(Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ])
>Delete template from image store: Prod-SecStor
>2014-01-17 16:06:41,836 DEBUG [storage.image.TemplateDataFactoryImpl]
>(Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ])
>template 203 is already in store:1, type:Image
>2014-01-17 16:06:41,956 DEBUG [agent.transport.Request]
>(Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ]) Seq
>5-2088570903: Sending  { Cmd , MgmtId: 99433950741773, via: 5, Ver: v1,
>Flags: 100011, 
>[{"org.apache.cloudstack.storage.command.DeleteCommand":{"data":{"org.apac
>he.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/5/203","
>origUrl":"http://cloudstack.ixxx.com/iso/WinServer_2008_R2_x64_ENG.ISO
>","uuid":"94e4ee85-c1af-4eac-b695-d5912a6c9c41","id":203,"format":"ISO","a
>ccountId":5,"hvm":true,"displayText":"Test
>2nd","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.10
>0.x.xxx/data/prod_zone","_role":"Image"}},"name":"203-5-7cca35bd-0eaa-37fe
>-a45a-418bcc5d9b96","hypervisorType":"None"}},"wait":0}}]
>}
>2014-01-17 16:06:42,054 DEBUG [agent.transport.Request]
>(AgentManager-Handler-6:null) Seq 5-2088570903: Processing:  { Ans: ,
>MgmtId: 99433950741773, via: 5, Ver: v1, Flags: 10,
>[{"com.cloud.agent.api.Answer":{"result":false,"details":"Unable to
>delete file 204 under Template path template/tmpl/5/203","wait":0}}] }
>2014-01-17 16:06:42,054 DEBUG [agent.transport.Request]
>(Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ]) Seq
>5-2088570903: Received:  { Ans: , MgmtId: 99433950741773, via: 5, Ver:
>v1, Flags: 10, { Answer } }
>2014-01-17 16:06:42,125 WARN [cloud.template.HypervisorTemplateAdapter]
>(Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ])
>Failed to delete the template
>Tmpl[203-ISO-203-5-7cca35bd-0eaa-37fe-a45a-418bcc5d9b96 from the image
>store: Prod-SecStor due to: Unable to delete file 204 under Template
>path template/tmpl/5/203
>2014-01-17 16:06:42,206 ERROR [cloud.async.AsyncJobManagerImpl]
>(Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ])
>Unexpected exception while executing
>org.apache.cloudstack.api.command.user.iso.DeleteIsoCmd
>com.cloud.utils.exception.CloudRuntimeException: Failed to delete ISO
> at 
>com.cloud.template.TemplateManagerImpl.deleteIso(TemplateManagerImpl.java:
>1120)
> at 
>com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorD
>ispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
> at 
>org.apache.cloudstack.api.command.user.iso.DeleteIsoCmd.execute(DeleteIsoC
>md.java:110)
> at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
> at 
>com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
> at 
>java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:
>1146)
> at 
>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java
>:615)
> at java.lang.Thread.run(Thread.java:701)
>
>-- 
>Francois Gaudreault
>Architecte de Solution Cloud | Cloud Solutions Architect
>fgaudrea...@cloudops.com
>514-629-6775
>- - -
>CloudOps
>420 rue Guy
>Montréal QC  H3J 1S6
>www.cloudops.com
>@CloudOps_
>

Re: Cannot delete ISO

[Francois Gaudreault]

Looks like it :) I just opened a ticket:
CLOUDSTACK-5900

Also, I would like to point out that my template was ID 203, and it was 
trying to delete the file/folder 204, which is not the proper directory...


Thanks!

FG

On 1/17/2014, 6:23 PM, Min Chen wrote:

This is a bug in deleting an ISO that is not successfully downloaded.

Thanks
-min

On 1/17/14 1:12 PM, "Francois Gaudreault"  wrote:


We have a fresh 4.2.1 install, and apparently we cannot delete ISO that
failed to download? We are using XenServer hypervisors.

2014-01-17 16:06:41,833 INFO [cloud.template.HypervisorTemplateAdapter]
(Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ])
Delete template from image store: Prod-SecStor
2014-01-17 16:06:41,836 DEBUG [storage.image.TemplateDataFactoryImpl]
(Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ])
template 203 is already in store:1, type:Image
2014-01-17 16:06:41,956 DEBUG [agent.transport.Request]
(Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ]) Seq
5-2088570903: Sending  { Cmd , MgmtId: 99433950741773, via: 5, Ver: v1,
Flags: 100011,
[{"org.apache.cloudstack.storage.command.DeleteCommand":{"data":{"org.apac
he.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/5/203","
origUrl":"http://cloudstack.ixxx.com/iso/WinServer_2008_R2_x64_ENG.ISO
","uuid":"94e4ee85-c1af-4eac-b695-d5912a6c9c41","id":203,"format":"ISO","a
ccountId":5,"hvm":true,"displayText":"Test
2nd","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.10
0.x.xxx/data/prod_zone","_role":"Image"}},"name":"203-5-7cca35bd-0eaa-37fe
-a45a-418bcc5d9b96","hypervisorType":"None"}},"wait":0}}]
}
2014-01-17 16:06:42,054 DEBUG [agent.transport.Request]
(AgentManager-Handler-6:null) Seq 5-2088570903: Processing:  { Ans: ,
MgmtId: 99433950741773, via: 5, Ver: v1, Flags: 10,
[{"com.cloud.agent.api.Answer":{"result":false,"details":"Unable to
delete file 204 under Template path template/tmpl/5/203","wait":0}}] }
2014-01-17 16:06:42,054 DEBUG [agent.transport.Request]
(Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ]) Seq
5-2088570903: Received:  { Ans: , MgmtId: 99433950741773, via: 5, Ver:
v1, Flags: 10, { Answer } }
2014-01-17 16:06:42,125 WARN [cloud.template.HypervisorTemplateAdapter]
(Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ])
Failed to delete the template
Tmpl[203-ISO-203-5-7cca35bd-0eaa-37fe-a45a-418bcc5d9b96 from the image
store: Prod-SecStor due to: Unable to delete file 204 under Template
path template/tmpl/5/203
2014-01-17 16:06:42,206 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ])
Unexpected exception while executing
org.apache.cloudstack.api.command.user.iso.DeleteIsoCmd
com.cloud.utils.exception.CloudRuntimeException: Failed to delete ISO
 at
com.cloud.template.TemplateManagerImpl.deleteIso(TemplateManagerImpl.java:
1120)
 at
com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorD
ispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
 at
org.apache.cloudstack.api.command.user.iso.DeleteIsoCmd.execute(DeleteIsoC
md.java:110)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
 at
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
 at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
 at java.util.concurrent.FutureTask.run(FutureTask.java:166)
 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:
1146)
 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java
:615)
 at java.lang.Thread.run(Thread.java:701)

--
Francois Gaudreault
Architecte de Solution Cloud | Cloud Solutions Architect
fgaudrea...@cloudops.com
514-629-6775
- - -
CloudOps
420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_







--
Francois Gaudreault
Architecte de Solution Cloud | Cloud Solutions Architect
fgaudrea...@cloudops.com
514-629-6775
- - -
CloudOps
420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_

Re: Cannot delete ISO

[Min Chen]

Yes. For ISO that is not successfully downloaded, in db
template_store_ref, that iso install_path has only up to the directory
template/tmpl//. In our delete logic, we always
assume that the install_path is up to the template file, which is not true
for those unsuccessfully installed ISO/template, thus the bug. In 4.2, UI
will not show those non-successfully downloaded ISO/template, and
therefore this is not an issue. In 4.2.1, code is changed to show failed
template/ISO, thus the bug surfaces.

Thanks
-min

On 1/17/14 3:33 PM, "Francois Gaudreault"  wrote:

>Looks like it :) I just opened a ticket:
>CLOUDSTACK-5900
>
>Also, I would like to point out that my template was ID 203, and it was
>trying to delete the file/folder 204, which is not the proper directory...
>
>Thanks!
>
>FG
>
>On 1/17/2014, 6:23 PM, Min Chen wrote:
>> This is a bug in deleting an ISO that is not successfully downloaded.
>>
>> Thanks
>> -min
>>
>> On 1/17/14 1:12 PM, "Francois Gaudreault" 
>>wrote:
>>
>>> We have a fresh 4.2.1 install, and apparently we cannot delete ISO that
>>> failed to download? We are using XenServer hypervisors.
>>>
>>> 2014-01-17 16:06:41,833 INFO [cloud.template.HypervisorTemplateAdapter]
>>> (Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ])
>>> Delete template from image store: Prod-SecStor
>>> 2014-01-17 16:06:41,836 DEBUG [storage.image.TemplateDataFactoryImpl]
>>> (Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ])
>>> template 203 is already in store:1, type:Image
>>> 2014-01-17 16:06:41,956 DEBUG [agent.transport.Request]
>>> (Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ]) Seq
>>> 5-2088570903: Sending  { Cmd , MgmtId: 99433950741773, via: 5, Ver: v1,
>>> Flags: 100011,
>>> 
>>>[{"org.apache.cloudstack.storage.command.DeleteCommand":{"data":{"org.ap
>>>ac
>>> 
>>>he.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/5/203"
>>>,"
>>> 
>>>origUrl":"http://cloudstack.ixxx.com/iso/WinServer_2008_R2_x64_ENG.I
>>>SO
>>> 
>>>","uuid":"94e4ee85-c1af-4eac-b695-d5912a6c9c41","id":203,"format":"ISO",
>>>"a
>>> ccountId":5,"hvm":true,"displayText":"Test
>>> 
>>>2nd","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.
>>>10
>>> 
>>>0.x.xxx/data/prod_zone","_role":"Image"}},"name":"203-5-7cca35bd-0eaa-37
>>>fe
>>> -a45a-418bcc5d9b96","hypervisorType":"None"}},"wait":0}}]
>>> }
>>> 2014-01-17 16:06:42,054 DEBUG [agent.transport.Request]
>>> (AgentManager-Handler-6:null) Seq 5-2088570903: Processing:  { Ans: ,
>>> MgmtId: 99433950741773, via: 5, Ver: v1, Flags: 10,
>>> [{"com.cloud.agent.api.Answer":{"result":false,"details":"Unable to
>>> delete file 204 under Template path template/tmpl/5/203","wait":0}}] }
>>> 2014-01-17 16:06:42,054 DEBUG [agent.transport.Request]
>>> (Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ]) Seq
>>> 5-2088570903: Received:  { Ans: , MgmtId: 99433950741773, via: 5, Ver:
>>> v1, Flags: 10, { Answer } }
>>> 2014-01-17 16:06:42,125 WARN [cloud.template.HypervisorTemplateAdapter]
>>> (Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ])
>>> Failed to delete the template
>>> Tmpl[203-ISO-203-5-7cca35bd-0eaa-37fe-a45a-418bcc5d9b96 from the image
>>> store: Prod-SecStor due to: Unable to delete file 204 under Template
>>> path template/tmpl/5/203
>>> 2014-01-17 16:06:42,206 ERROR [cloud.async.AsyncJobManagerImpl]
>>> (Job-Executor-21:job-54 = [ 934ed1bf-c382-42f4-b5fe-3bcd0284dfb8 ])
>>> Unexpected exception while executing
>>> org.apache.cloudstack.api.command.user.iso.DeleteIsoCmd
>>> com.cloud.utils.exception.CloudRuntimeException: Failed to delete ISO
>>>  at
>>> 
>>>com.cloud.template.TemplateManagerImpl.deleteIso(TemplateManagerImpl.jav
>>>a:
>>> 1120)
>>>  at
>>> 
>>>com.cloud.utils.component.ComponentInstantiationPostProcessor$Intercepto
>>>rD
>>> ispatcher.intercept(ComponentInstantiationPostProcessor.java:125)
>>>  at
>>> 
>>>org.apache.cloudstack.api.command.user.iso.DeleteIsoCmd.execute(DeleteIs
>>>oC
>>> md.java:110)
>>>  at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:158)
>>>  at
>>> com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:531)
>>>  at
>>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
>>>  at 
>>>java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
>>>  at java.util.concurrent.FutureTask.run(FutureTask.java:166)
>>>  at
>>> 
>>>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav
>>>a:
>>> 1146)
>>>  at
>>> 
>>>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja
>>>va
>>> :615)
>>>  at java.lang.Thread.run(Thread.java:701)
>>>
>>> -- 
>>> Francois Gaudreault
>>> Architecte de Solution Cloud | Cloud Solutions Architect
>>> fgaudrea...@cloudops.com
>>> 514-629-6775
>>> - - -
>>> CloudOps
>>> 420 rue Guy
>>> Montréal QC  H3J 1S6
>>> www.cloudops.com
>>> @CloudOps_
>>>
>>
>>
>
>
>-- 
>Francois Gaudreault
>Archi

Re: Revert "update packages list before getting jre 7"

[Abhinandan Prateek]

Sure, good learning will follow the steps.

On 17/01/14 10:35 pm, "Hugo Trippaers"  wrote:

>Thanks Abhi,
>
>Can you raise the bug and apply them on master?  Maybe it’s also good to
>write to the list which this upgrade is required. There is a thread on
>upgrading to java 7 that might be interesting to refer to.
>
>Cheers,
>
>Hugo
>
>
>On 17 jan. 2014, at 17:58, Abhinandan Prateek
> wrote:
>
>> I have reverted another related one
>> fc2e7ec70a1cc48a10a168ec3df607b49a7bcdf6, that was updating the jre to
>> version 7. 
>> 
>> -abhi
>> 
>> On 17/01/14 10:11 pm, "Hugo Trippaers"  wrote:
>> 
>>> Hey guys,
>>> 
>>> I just reverted commit fa6536152a17dfd03b6eb10b2a1e0868fc9e134c
>>> 
>>> The branch 4.3 is a release branch, not a playground. We are inches
>>>away
>>> from a release, this means that nothing goes into the branch without
>>> being expressly permitted by the release manager. This case is even
>>>worse
>>> as the change wasn¹t even made in master, the leading branch.
>>> 
>>> Just a general reminder about the process.
>>> 
>>> 1. Create a ticket for your bug (if its not a bug, its not going to be
>>>in
>>> 4.3 anyway)
>>> 2. Make your changes in master
>>> 3. Test them on master
>>> 4. Send mail to dev list to ask permission from the release manager to
>>> back port to 4.3 and include the test result
>>> 
>>> Please stick to this game plan, so we can have a speedy release of 4.3.
>>> 
>>> 
>>> Cheers,
>>> 
>>> Hugo
>> 
>

Re: systemvm templates

[Hugo Trippaers]

Hey Abhi,

Do you have more details on this? A stacktrace or error log would be great.

I would really need to see the details before we make a decision on this.

Cheers,

Hugo

Sent from my iPhone

> On 17 jan. 2014, at 23:42, Abhinandan Prateek  
> wrote:
> 
> In SSVM for VMWare, copying template to primary storage fails in some
> cases with jre 6. 
> 
> -abhi
> 
>> On 18/01/14 1:08 am, "Alex Huang"  wrote:
>> 
>> Why is jre7 required for vmware?  Kelven, you have any idea?
>> 
>> --Alex
>> 
>>> -Original Message-
>>> From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
>>> Sent: Friday, January 17, 2014 9:08 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: systemvm templates
>>> 
>>> Hugo,
>>> 
>>>  First of all my bad that I jumped the gun on jre7 change. I will be
>>> testing the
>>> full build on master and then update the urls and other changes.
>>> In the current template jre7 package is not available by default, needs
>>> apt-
>>> get update. jre7 is a absolute necessity for VMWare template.
>>> 
>>> Once I have a successful local build I will update the thread.
>>> 
>>> -abhi
>>> 
>>> 
 On 17/01/14 10:20 pm, "Hugo Trippaers"  wrote:
 
 Abhi,
 
 I have the debian 7.0.0 isis local on the jenkins server, so we don¹t
 depend on the external URLs.
 
 Do you want to switch master to the new image? No trouble for me to
 make it happen.
 
 Cheers,
 
 Hugo
 
 On 17 jan. 2014, at 17:12, Abhinandan Prateek
  wrote:
 
> 
> While trying to build systemvm templates I noticed that the urls to
> download the debian images are invalid as in definition.rb in
> respective
> folders:
> 
> For 64 bit template
> http://cdimage.debian.org/mirror/cdimage/archive/7.0.0/i386/iso-cd/deb
> ian
> -7.0.0-i386-netinst.iso
> For 32 bit template
> http://cdimage.debian.org/mirror/cdimage/archive/7.0.0/i386/iso-cd/deb
> ian
> -7.0.0-i386-netinst.iso
> 
> I will be updating these to following respectively, once I have a
> successful local build:
> 
> 
> http://ftp.acc.umu.se/mirror/cdimage/release/7.3.0/i386/iso-cd/debian-
>>> 7.3
> .0-i386-netinst.iso   MD5: 04c58f30744e64a0459caf7d7cace479
> 
> http://ftp.acc.umu.se/mirror/cdimage/release/7.3.0/ia64/iso-cd/debian-
> 7.3 .0-ia64-netinst.iso  MD5: a6b93666a5393334accb7ac4ee28d949
> 
> Not sure if jenkins job is building the right templates now ?
> 
> -abhi
>