Re: Review Request 16540: CLOUDSTACK-5692: cleanup API response for primary/secondary storages
---
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=administratordomain=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
---
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=administratordomain=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
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 run...@gmail.com wrote: On Jan 15, 2014, at 11:01 AM, Sean Hamilton s...@seanhamilton.co.uk 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 terbol...@gmail.com wrote: On Thu, Jan 9, 2014 at 12:07 PM, Sean Hamilton s...@seanhamilton.co.uk 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
See http://jenkins.buildacloud.org/job/build-master/76/changes 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 http://jenkins.buildacloud.org/job/build-master/ws/plugins/storage/volume/solidfire/target/test-classes [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 http://jenkins.buildacloud.org/job/build-master/ws/plugins/storage/volume/default/target (includes = [**/*], excludes = []) [INFO] Deleting http://jenkins.buildacloud.org/job/build-master/ws/plugins/storage/volume/default (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 http://jenkins.buildacloud.org/job/build-master/ws/plugins/storage/volume/default/target/classes [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 http://jenkins.buildacloud.org/job/build-master/ws/plugins/storage/volume/default/test/resources [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 http://jenkins.buildacloud.org/job/build-master/ws/plugins/storage/volume/sample/target (includes = [**/*], excludes = []) [INFO] Deleting http://jenkins.buildacloud.org/job/build-master/ws/plugins/storage/volume/sample (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 http://jenkins.buildacloud.org/job/build-master/ws/plugins/storage/volume/sample/resources [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 http://jenkins.buildacloud.org/job/build-master/ws/plugins/storage/volume/sample/target/classes [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 http://jenkins.buildacloud.org/job/build-master/ws/plugins/storage/volume/sample/test/resources [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-plugin:2.12:test
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
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) j...@apache.org [ https://issues.apache.org/jira/browse/CLOUDSTACK-5834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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(Thread.java:679) 2014-01-08 13:15:08,371 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-141:ctx-74d0d04a) Seq 1-498139202: Response
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=hypervpassword=hypervdomain=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=hypervpassword=hyperv13!domain=angusnet.local,
port: 445,
url:
NetworkFilesystem://10.0.1.27//hypervPri/stor?user=hypervpassword=hyperv13!domain=angusnet.local/?ROLE=PrimarySTOREUUID=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.HypervResourceController
[cc482c9e-0d97-4be8-9dc8-2e546bdb00c1] -
org.apache.cloudstack.storage.command.CopyCommand failed on exception, net use
of share
Re: Review Request 13560: CLOUDSTACK-4021 : Update the test test_explicit_dedication.py according to new changes to dedicated resources
--- 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
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
See http://jenkins.buildacloud.org/job/build-master/77/changes
Re: IPv6 in VPC (was Re: IPv6 plan - questions)
On Fri, Jan 17, 2014 at 8:45 AM, Marcus Sorensen shadow...@gmail.com 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)
Ok, I though those could come from the same vpc range. On Fri, Jan 17, 2014 at 2:58 PM, Marcus Sorensen shadow...@gmail.com 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 daan.hoogl...@gmail.com wrote: On Fri, Jan 17, 2014 at 8:45 AM, Marcus Sorensen shadow...@gmail.com 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
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=listHostsresponse=jsonsessionkey=tPdf1uSuogiM1ubmRFuPuFV%2FLzM%3Dpage=1pageSize=20type=routinglistAll=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éal QC
Re: Issues after upgrading CS from 4.1 to 4.2.1 managing XenServer 6.0.2 clusters
same issue: CLOUDSTACK-5834
2014/1/17 Pierre-Luc Dion pd...@cloudops.com
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=listHostsresponse=jsonsessionkey=tPdf1uSuogiM1ubmRFuPuFV%2FLzM%3Dpage=1pageSize=20type=routinglistAll=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
Re: Change SCSI type in VMware
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 sateesh.chodapune...@citrix.com 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 run...@gmail.com wrote: On Jan 15, 2014, at 11:01 AM, Sean Hamilton s...@seanhamilton.co.uk 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 terbol...@gmail.com wrote: On Thu, Jan 9, 2014 at 12:07 PM, Sean Hamilton s...@seanhamilton.co.uk 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-noredist #2122
See http://jenkins.buildacloud.org/job/build-master-noredist/2122/changes 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 http://jenkins.buildacloud.org/job/build-master-noredist/ws/awsapi/target/generated-webapp/WEB-INF/classes [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 http://jenkins.buildacloud.org/job/build-master-noredist/ws/awsapi/target/classes [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
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
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
See http://jenkins.buildacloud.org/job/build-master-noredist/2123/changes
Re: Issues after upgrading CS from 4.1 to 4.2.1 managing XenServer 6.0.2 clusters
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 ustcweiz...@gmail.com wrote:
same issue: CLOUDSTACK-5834
2014/1/17 Pierre-Luc Dion pd...@cloudops.com
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
Re: systemvm templates
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 abhinandan.prat...@citrix.com 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
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 h...@trippaers.nl 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, 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 h...@trippaers.nl 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 abhinandan.prat...@citrix.com 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
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 abhinandan.prat...@citrix.com 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 h...@trippaers.nl 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
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.init(CloudStackSpringContext.java:56)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(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
Re: systemvm templates
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
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 abhinandan.prat...@citrix.com 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
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 s...@packtpub.com 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
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 brian.fede...@citrix.com 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 brian.fede...@citrix.com 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
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 brian.fede...@citrix.com 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 brian.fede...@citrix.com 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
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 abhinandan.prat...@citrix.com 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 h...@trippaers.nl 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 abhinandan.prat...@citrix.com 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
Have to agree with this. On 1/17/14 10:42 AM, Jessica Wang jessica.w...@citrix.com 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 brian.fede...@citrix.com 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 brian.fede...@citrix.com 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
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 brian.fede...@citrix.com 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 brian.fede...@citrix.com 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)
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 shadow...@gmail.com 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 chiradeep.vit...@citrix.com 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 sh...@yasker.org wrote: On Thu, Jan 9, 2014 at 7:04 AM, Daan Hoogland dhoogl...@schubergphilis.comwrote: 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
RE: CS4.1+xenserver 6.1 snapshot error
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=task-record-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: none/
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:job-3754) Seq 4-823396163:
Re: IPv6 in VPC (was Re: IPv6 plan - questions)
On Thu, Jan 16, 2014 at 11:19 PM, Marcus Sorensen shadow...@gmail.comwrote: On Thu, Jan 16, 2014 at 12:33 PM, Sheng Yang sh...@yasker.org 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, modifying the upstream router automatically make me feel unsafe... Probably host side is a better choice, though it would be more work to do. Do we care about portforwarding, static NAT, Load Balancing etc as well? Or at least think
RE: systemvm templates
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 h...@trippaers.nl 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 abhinandan.prat...@citrix.com 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
On Jan 17, 2014, at 1:41 PM, Brian Federle brian.fede...@citrix.com 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 brian.fede...@citrix.com 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 brian.fede...@citrix.com 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
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 brian.fede...@citrix.com 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 brian.fede...@citrix.com 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 brian.fede...@citrix.com 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
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 brian.fede...@citrix.com 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 brian.fede...@citrix.com 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 brian.fede...@citrix.com 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 Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ offers
Build failed in Jenkins: cloudstack-4.3-maven-build #431
See http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build/431/changes
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:
http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build/ws/engine/components-api/target/surefire-reports
---
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
http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build/ws/server
(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
http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build/ws/server/target/conf
[copy] Copying 1 file to
http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build/ws/server/target/conf
[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
http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build/ws/server/target/classes
[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
http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build/ws/server/target/test-classes
[INFO]
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ cloud-server ---
[INFO] Surefire report directory:
http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build/ws/server/target/surefire-reports
---
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= 100 Queue size = 100 time=2493 ms
Total jobs
Cannot delete ISO
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)
On Fri, Jan 17, 2014 at 11:59 AM, Chiradeep Vittal chiradeep.vit...@citrix.com 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 shadow...@gmail.com 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 chiradeep.vit...@citrix.com 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 sh...@yasker.org wrote: On Thu, Jan 9, 2014 at 7:04 AM, Daan Hoogland dhoogl...@schubergphilis.comwrote: 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
Build failed in Jenkins: build-master-noredist #2126
See http://jenkins.buildacloud.org/job/build-master-noredist/2126/changes 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 http://jenkins.buildacloud.org/job/build-master-noredist/ws/quickcloud/src/test/resources [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: http://jenkins.buildacloud.org/job/build-master-noredist/ws/quickcloud/target/surefire-reports --- 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: http://jenkins.buildacloud.org/job/build-master-noredist/ws/quickcloud/target/cloud-quickcloud-4.4.0-SNAPSHOT.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 http://jenkins.buildacloud.org/job/build-master-noredist/ws/quickcloud/target/cloud-quickcloud-4.4.0-SNAPSHOT.jar to /jenkins/.m2/repository/org/apache/cloudstack/cloud-quickcloud/4.4.0-SNAPSHOT/cloud-quickcloud-4.4.0-SNAPSHOT.jar [INFO] Installing http://jenkins.buildacloud.org/job/build-master-noredist/ws/quickcloud/pom.xml 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-jdk14:jar:1.5.2 is invalid,
Re: systemvm templates
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 alex.hu...@citrix.com 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 h...@trippaers.nl 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 abhinandan.prat...@citrix.com 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
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
See http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build/432/changes
Re: Cannot delete ISO
This is a bug in deleting an ISO that is not successfully downloaded.
Thanks
-min
On 1/17/14 1:12 PM, Francois Gaudreault fgaudrea...@cloudops.com 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
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 fgaudrea...@cloudops.com 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
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/account_id/template_id. 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 fgaudrea...@cloudops.com 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 fgaudrea...@cloudops.com
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
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: Revert update packages list before getting jre 7
Sure, good learning will follow the steps. On 17/01/14 10:35 pm, Hugo Trippaers h...@trippaers.nl 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 abhinandan.prat...@citrix.com 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 h...@trippaers.nl 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
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 abhinandan.prat...@citrix.com 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 alex.hu...@citrix.com 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 h...@trippaers.nl 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 abhinandan.prat...@citrix.com 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
