Re: [ASK] Is password server disabled in VPC?
I was kidding, Rohit. Good job :) -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Rohit Yadav rohit.ya...@shapeblue.com To: dev@cloudstack.apache.org Sent: Wednesday, 18 March, 2015 05:16:09 Subject: Re: [ASK] Is password server disabled in VPC? Hi all, On 17-Mar-2015, at 6:25 pm, Nux! n...@li.nux.ro wrote: Looks like Rohit managed to get us to panic. Again! :-) Sorry for the issue, I did n’t mean to cause any panic :) It was a bug which caused the password server to not start. After Ian pointed out how it works for VPCs I was able to fix it. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: SNAT and remote IP problem
I reacall this was fine in clean 4.4.0 or 4.4.1/2cant remember any more... but anyone willing to share their VR output, as I asked, will I guess help us greatly... On 18 March 2015 at 12:28, Erik Weber terbol...@gmail.com wrote: Has anyone checked if this is present in 4.5? If so we should aim to have a fix available with 4.5.1 -- Erik On Wed, Mar 18, 2015 at 10:47 AM, Paul Shadwell shadw...@me.com wrote: I also have this problem, it effects running vPBX/VoIP services behind a VR. In fact any service that requires a view on incoming IPs and domain names. For example fail2ban will block ALL access to ssh because it only ever sees the VR IP address. Upgrading to 4.3.2 did not fix it. This needs fixing urgently. Best regards Paul On 17 Mar 2015, at 14:01, Andrija Panic andrija.pa...@gmail.com wrote: Hi, is anybody willing to share the result from the folowing command, run in VR (VPC VR): iptables -t nat -nvL This should preferable be run from SSH-to-VR, instead of ConsoleProxy-to-VR, because of nice output over SSH. It seems in 4.3.0 and 4.3.2, SNAT is done on ALL incoming connections, no matter to WHAT IP the traffic from internet came - primary IP, or additional one that is used for i.e. Static NAT - so SNAT rules always replace remote cleint IP with MAIN IP of the VPC... Please share your examples - this is serious bug in my opinion, and I wil raise JIRA - but would like some examples from other guys first. THanks, -- Andrija Panić -- Andrija Panić
Build failed in Jenkins: build-4.5 #404
See http://jenkins.buildacloud.org/job/build-4.5/404/changes
Changes:
[Rohit Yadav] CLOUDSTACK-8331: have savepassword try all interfaces
--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on cloudstack-buildslave-centos6-9ee
(cloudstack-buildslave-centos6) in workspace
http://jenkins.buildacloud.org/job/build-4.5/ws/
/usr/bin/git rev-parse --is-inside-work-tree # timeout=400
Fetching changes from the remote Git repository
/usr/bin/git config remote.origin.url
https://git-wip-us.apache.org/repos/asf/cloudstack.git # timeout=400
Fetching upstream changes from
https://git-wip-us.apache.org/repos/asf/cloudstack.git
/usr/bin/git --version # timeout=400
/usr/bin/git fetch --tags --progress
https://git-wip-us.apache.org/repos/asf/cloudstack.git
+refs/heads/*:refs/remotes/origin/*
/usr/bin/git rev-parse refs/remotes/origin/4.5^{commit} # timeout=400
/usr/bin/git rev-parse refs/remotes/origin/origin/4.5^{commit} # timeout=400
Checking out Revision b8192114767040ef4869a7e71886df5965dadb37
(refs/remotes/origin/4.5)
/usr/bin/git config core.sparsecheckout # timeout=400
/usr/bin/git checkout -f b8192114767040ef4869a7e71886df5965dadb37
/usr/bin/git rev-list 3262b0bfd99528fd74a1693185544948f4d951ef # timeout=400
[copy-to-slave] Copying 'settings.xml', excluding nothing, from
'file:/var/lib/jenkins/userContent/' on the master to
'http://jenkins.buildacloud.org/job/build-4.5/ws/' on
'cloudstack-buildslave-centos6-9ee'.
[build-4.5] $
/jenkins/tools/hudson.tasks.Maven_MavenInstallation/maven-3.1.1/bin/mvn -s
http://jenkins.buildacloud.org/job/build-4.5/ws/settings.xml
-Psystemvm,awsapi -T 2C clean test
Error occurred during initialization of VM
java.lang.OutOfMemoryError: unable to create new native thread
Build step 'Invoke top-level Maven targets' marked build as failure
Recording test results
ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception
hudson.AbortException: Test reports were found but none of them are new. Did
tests run?
For example,
http://jenkins.buildacloud.org/job/build-4.5/ws/agent/target/surefire-reports/TEST-com.cloud.agent.AgentShellTest.xml
is 26 days old
at hudson.tasks.junit.TestResult.parse(TestResult.java:178)
at hudson.tasks.junit.TestResult.parse(TestResult.java:146)
at hudson.tasks.junit.TestResult.init(TestResult.java:122)
at
hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:119)
at
hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:93)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2665)
at hudson.remoting.UserRequest.perform(UserRequest.java:121)
at hudson.remoting.UserRequest.perform(UserRequest.java:49)
at hudson.remoting.Request$2.run(Request.java:324)
at
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
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)
at ..remote call to cloudstack-buildslave-centos6-9ee(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:221)
at hudson.remoting.Channel.call(Channel.java:752)
at hudson.FilePath.act(FilePath.java:970)
at hudson.FilePath.act(FilePath.java:959)
at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:90)
at
hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120)
at
hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137)
at
hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770)
at
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734)
at hudson.model.Build$BuildExecution.post2(Build.java:183)
at
hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683)
at hudson.model.Run.execute(Run.java:1784)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
Re: SNAT and remote IP problem
Has anyone checked if this is present in 4.5? If so we should aim to have a fix available with 4.5.1 -- Erik On Wed, Mar 18, 2015 at 10:47 AM, Paul Shadwell shadw...@me.com wrote: I also have this problem, it effects running vPBX/VoIP services behind a VR. In fact any service that requires a view on incoming IPs and domain names. For example fail2ban will block ALL access to ssh because it only ever sees the VR IP address. Upgrading to 4.3.2 did not fix it. This needs fixing urgently. Best regards Paul On 17 Mar 2015, at 14:01, Andrija Panic andrija.pa...@gmail.com wrote: Hi, is anybody willing to share the result from the folowing command, run in VR (VPC VR): iptables -t nat -nvL This should preferable be run from SSH-to-VR, instead of ConsoleProxy-to-VR, because of nice output over SSH. It seems in 4.3.0 and 4.3.2, SNAT is done on ALL incoming connections, no matter to WHAT IP the traffic from internet came - primary IP, or additional one that is used for i.e. Static NAT - so SNAT rules always replace remote cleint IP with MAIN IP of the VPC... Please share your examples - this is serious bug in my opinion, and I wil raise JIRA - but would like some examples from other guys first. THanks, -- Andrija Panić
Build failed in Jenkins: simulator-singlerun #1032
See http://jenkins.buildacloud.org/job/simulator-singlerun/1032/changes Changes: [wrodrigues] CLOUDSTACK-7143: a better fix for kernel upgrade disk space problems [wrodrigues] Make sure the location for the persistant configs exists [wrodrigues] Switch ip associations to the new config file system [wrodrigues] Removed useless array from SetStaticRoutesCmd. [wrodrigues] Cherry-pick of 11c00977f77f45aa7b0c387dc88360eba0819e8a: [wrodrigues] This file isn't used, so remove it [wrodrigues] Add a placeholder for the trigger file [wrodrigues] Vagrant virtualbox based testing suite [wrodrigues] Added curl to the base install [wrodrigues] Merged cookbooks from vpc branch [wrodrigues] Remove scripts directory no longer necessary [wrodrigues] Replace CreateGuestNetwork config script with a json file. [wrodrigues] Tuning/reformatting/defensible-ing Vagrantfile [wrodrigues] Add the Python bits [wrodrigues] Added cs_ip module [wrodrigues] Use json naming standards instead of camelCase [wrodrigues] Changed from camelCase to json_case [wrodrigues] Create a json file for SetNetworkACL [wrodrigues] Only ip_association files for now [wrodrigues] Can now read the ips out of the cmdline databag (if present) [wrodrigues] Correct small typo in error message [wrodrigues] Remove debug code [wrodrigues] Include a type field in all json configuration objects [wrodrigues] Switch ip associations to new model and update the recipes [wrodrigues] Disable cmdline check until it's fixed [wrodrigues] 1. Completed provider for ip rules (fwmark) [wrodrigues] Corrected a hole in my logic [wrodrigues] Rewrite networkacl model to have separate entries for each rule [wrodrigues] Add some debug logging to keep track of timing [wrodrigues] Change vmdata to the new config system [wrodrigues] A working test-kitchen setup for testing systemvm boxes. [wrodrigues] Include the guestnetwork code [wrodrigues] Split Databag in to separate class as I would now need this [wrodrigues] junit report output for vagrant systemvm tests [wrodrigues] Use bundler to exec test-kitchen [wrodrigues] Commit missing .kitchen.yml [wrodrigues] Massively simpler serverspec invocation [wrodrigues] Missing gem for vagrant magic [wrodrigues] Documentation and license headers for new systemvm testing tools. [wrodrigues] Plan B [wrodrigues] Test data for ipassociation [wrodrigues] Added some lost lines back using Hugo witchcraft [wrodrigues] Put a netmask in the netmask field [wrodrigues] Moved bag location to /et/cloudstack [wrodrigues] Pure python tests for systemvm [wrodrigues] Replace serverspec with nose in systemvm test.sh [wrodrigues] Attempt to get these tests working on python 2.6 [wrodrigues] Second Attempt to get these tests working on python 2.6. [wrodrigues] Added guest network configuration [wrodrigues] This was a good one [wrodrigues] Move some static strings to constants and remove some duplicate code [wrodrigues] New style save password command [wrodrigues] Fancy line editor for Ian [wrodrigues] Don't fail if you've logged into an older systemvm manually, before. [wrodrigues] Set up rsync for systemvm patches. [wrodrigues] Fix update_config.py use of subprocess. [wrodrigues] Fix configure::waitForDevice when a device is missing. [wrodrigues] Tests for update_config.py [wrodrigues] Add forwarding rules to the new config format and do a little rewrite on [wrodrigues] Removed merge_cline - no longer required [wrodrigues] New style manage VPN user command Still need some testing with the VR image [wrodrigues] Add more nics by default [wrodrigues] Have Vagrantfile errors go to STDERR so output is machine-parseable. [wrodrigues] Adding the Vagrant configuration that will build xen and db servers. [wrodrigues] modified StaticNatRule to use the new style [wrodrigues] iDo not do the post configure steps on a control interface [wrodrigues] Removed chef as we will definitely not go this way [wrodrigues] Migrate ip alias commands [wrodrigues] Do not use eth0 or eth1 for random tests [wrodrigues] Stop ignoring eth0 [wrodrigues] Fix on error reporting (null doesn't say much, so lets return the actual problem) [wrodrigues] Adding new model for the Site2SiteVpn configuration. [wrodrigues] Added some tests that test stuff [wrodrigues] Change the location for the temporary json files to /var/cache/cloud [wrodrigues] Staticroutes to new json style [wrodrigues] New model for RemoteAccessVpn and moving into the new structure [wrodrigues] Hotfix for lost control interface [wrodrigues] Small fixes [wrodrigues] Creating new model for the MonitorService [wrodrigues] Added vmpassword type (does nothing yet) [wrodrigues] New style dnsmasq configuration [wrodrigues] Fixed test (assert in guest check was wrong way around) [wrodrigues] Creating new model for the firewall rules [wrodrigues] Some bug fixes [wrodrigues] fixing the nullpointer on type which is null [wrodrigues] Fixed bug in which
Re: SNAT and remote IP problem
I also have this problem, it effects running vPBX/VoIP services behind a VR. In fact any service that requires a view on incoming IPs and domain names. For example fail2ban will block ALL access to ssh because it only ever sees the VR IP address. Upgrading to 4.3.2 did not fix it. This needs fixing urgently. Best regards Paul On 17 Mar 2015, at 14:01, Andrija Panic andrija.pa...@gmail.com wrote: Hi, is anybody willing to share the result from the folowing command, run in VR (VPC VR): iptables -t nat -nvL This should preferable be run from SSH-to-VR, instead of ConsoleProxy-to-VR, because of nice output over SSH. It seems in 4.3.0 and 4.3.2, SNAT is done on ALL incoming connections, no matter to WHAT IP the traffic from internet came - primary IP, or additional one that is used for i.e. Static NAT - so SNAT rules always replace remote cleint IP with MAIN IP of the VPC... Please share your examples - this is serious bug in my opinion, and I wil raise JIRA - but would like some examples from other guys first. THanks, -- Andrija Panić
Build failed in Jenkins: build-master-slowbuild #1129
See http://jenkins.buildacloud.org/job/build-master-slowbuild/1129/changes Changes: [Rohit Yadav] CLOUDSTACK-8331: have savepassword try all interfaces -- [...truncated 23731 lines...] [INFO] [INFO] --- cobertura-maven-plugin:2.7:cobertura (default-cli) @ cloud-awsapi --- [INFO] Cobertura 2.1.1 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file [INFO] Cobertura: Loaded information on 6393 classes. [INFO] Data file does not contain instrumentation information for the file com/amazon/ec2/AmazonEC2SkeletonInterface.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/amazon/s3/AmazonS3SkeletonInterface.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/model/SAcl.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/model/SBucket.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/model/SHost.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/BucketPolicyDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/CloudStackAccountDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/CloudStackConfigurationDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/CloudStackSvcOfferingDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/CloudStackUserDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MHostDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MHostMountDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MultiPartPartsDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MultiPartUploadsDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MultipartMetaDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/OfferingDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/SAclDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/SBucketDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/SHostDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/SMetaDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file
Build failed in Jenkins: build-master-slowbuild #1128
See http://jenkins.buildacloud.org/job/build-master-slowbuild/1128/changes Changes: [Rohit Yadav] vpc_passwd_server: use the improved Python based password server [Rohit Yadav] Add missing license headers from recent branch merge 3c429ee -- [...truncated 23731 lines...] [INFO] [INFO] --- cobertura-maven-plugin:2.7:cobertura (default-cli) @ cloud-awsapi --- [INFO] Cobertura 2.1.1 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file [INFO] Cobertura: Loaded information on 6393 classes. [INFO] Data file does not contain instrumentation information for the file com/amazon/ec2/AmazonEC2SkeletonInterface.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/amazon/s3/AmazonS3SkeletonInterface.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/model/SAcl.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/model/SBucket.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/model/SHost.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/BucketPolicyDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/CloudStackAccountDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/CloudStackConfigurationDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/CloudStackSvcOfferingDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/CloudStackUserDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MHostDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MHostMountDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MultiPartPartsDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MultiPartUploadsDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MultipartMetaDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/OfferingDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/SAclDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/SBucketDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/SHostDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/SMetaDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information.
Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205)
On Mar 18, 2015, at 10:43 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Diwas, The idea is to support Docker in ACS, much like LXC since they are similar (containers). This of course would have some limitations wrt supporting various network models and disk operations such as taking snapshot and migrations across hosts. ((Btw, you may also consider supporting Bhyve (VMM from FreeBSD community) in CloudStack using libvirt which is another interesting project.)) Irrespective of what base OS (RancherOS, CoreOS or Atomic etc) will be, assume it will be at least Linux 3.16. Assume using barebone technologies instead of relying on other orchestration or high level systems to control Docker images unless what you're willing to use are stable enough. While it's an open discussion on what the scope or the best way to do it; IMO, the basic things I'm looking for are: - Support Basic networking (supporting at least Linux bridge or maybe OVS - I'm not sure the best way to do it) - SystemVMs can be Docker based or VMs running on KVM - Local or NFS based shared storage. Support basic operations such as - upload/register template, create VMs using template. - Console proxy support (if possible). Since most players in the docker arena are still figuring out best way to deal with networking and storage, the expectation of the work is limited to producing an experimental hypervisor plugin. For implementation details, read CloudStack 101 on the wiki, see how plugins are written and follow the LXC plugin implementation or see this commit: https://github.com/apache/cloudstack/commit/c27c69438ba23386bac7ae4dd651b1d809811157 I understand why we you would like to do this, however I see Docker as a ‘workload’. It is easy to setup in a VM or bare metal. The Docker ecosystem is booming and there are a ton of Docker “orchestrator” being worked on. It seems to me it will be very difficult to keep up development of a proper docker management service in CloudStack. Personally, I’d rather see us put efforts in properly supporting all the new Docker customized OS (making cloudstack templates for them), fixing our cloudinit support and extending our API to create clusters of machines. That way it will be easy for CloudStack users to start a Docker cluster and use their docker container orchestrator of choice. Very much like if you want to deploy Mesos or the like in CloudStack, Docker orchestrators are really workloads in our clouds. Our strategy for Docker support should be to make it extremely easy for folks to use Docker in CloudStack VMs. Do things like Docker machine support, Docker swarm support etc….and if we want a tighter integration we should look at the AWS ECS API and the GCE container engine API and extend our EC2/GCE bridges to support them. my 2 cts. On Monday 16 March 2015 02:53 AM, Diwas Joshi wrote: hello, I would like to work on the following issue for https://issues.apache.org/jira/browse/CLOUDSTACK-8205 for google summer of code 2015. It would be really helpful if someone can tell me more about the idea and provide guidelines to get started with this. regards -- Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 8826230892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab PS. If you see any footer below, I did not add it :) Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205)
I'd really love to see this. CoreOS seems pretty well developed, with etcd and fleet. I envisage you would have clusters/pods of CoreOS machines with Cloudstack managing etcd discovery. Perhaps you could then define fleet unit files and have Cloudstack launch these on the CoreOS cluster. On Mon, Mar 16, 2015 at 8:45 AM, Nux! n...@li.nux.ro wrote: I had a look at Atomic, the CentOS image should theoretically work with Cloudstack; but in practice it does not (cloud-init fails). When I'll get some more time I'll look more into it and perhaps we can get that fixed. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Sebastien Goasguen run...@gmail.com To: dev@cloudstack.apache.org Sent: Monday, 16 March, 2015 07:33:34 Subject: Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205) On Mar 16, 2015, at 6:43 AM, Kishan Kavala kishan.kav...@citrix.com wrote: CoreOS is supported on CS. Templates are available here: http://dl.openvm.eu/cloudstack/coreos/x86_64/ There and on the official coreOS download site. It’s been available for a while now. It would be very nice for someone to look at creating CS templates for Atomic, Snappy and coreOS … We should have all docker minimal OS supported under CloudStack. Still, I think it is working exploring Docker as a hypervisor also. Tuna stared some work on this earlier: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Supporting+Docker+as+a+hypervisor http://ngtuna.blogspot.in/2013/12/docker-in-cloudstack.html https://issues.apache.org/jira/browse/CLOUDSTACK-6664 -Original Message- From: Koushik Das [mailto:koushik@citrix.com] Sent: Monday, March 16, 2015 10:49 AM To: dev@cloudstack.apache.org Subject: RE: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205) This is another alternate https://coreos.com/using-coreos/containers/. CS needs to support CoreOS. -Original Message- From: Diwas Joshi [mailto:dj.dij...@gmail.com] Sent: Monday, 16 March 2015 2:53 To: dev@cloudstack.apache.org Subject: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205) hello, I would like to work on the following issue for https://issues.apache.org/jira/browse/CLOUDSTACK-8205 for google summer of code 2015. It would be really helpful if someone can tell me more about the idea and provide guidelines to get started with this. regards
Let's start 4.5.1 release process?
Hi all, I've been testing and fixing issues in the past weeks on 4.5. I think 4.5 is in a better state and we've upgrade paths from 4.5.0 to 4.5.1 and 4.5.1 to 4.6.0 (master) as well. Has anyone found any blockers or issues that should be addressed on 4.5? David - If we're all good, let's cut a RC soon and release 4.5.1? Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 8826230892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab PS. If you see any footer below, I did not add it :) Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205)
Hi Diwas, The idea is to support Docker in ACS, much like LXC since they are similar (containers). This of course would have some limitations wrt supporting various network models and disk operations such as taking snapshot and migrations across hosts. ((Btw, you may also consider supporting Bhyve (VMM from FreeBSD community) in CloudStack using libvirt which is another interesting project.)) Irrespective of what base OS (RancherOS, CoreOS or Atomic etc) will be, assume it will be at least Linux 3.16. Assume using barebone technologies instead of relying on other orchestration or high level systems to control Docker images unless what you're willing to use are stable enough. While it's an open discussion on what the scope or the best way to do it; IMO, the basic things I'm looking for are: - Support Basic networking (supporting at least Linux bridge or maybe OVS - I'm not sure the best way to do it) - SystemVMs can be Docker based or VMs running on KVM - Local or NFS based shared storage. Support basic operations such as - upload/register template, create VMs using template. - Console proxy support (if possible). Since most players in the docker arena are still figuring out best way to deal with networking and storage, the expectation of the work is limited to producing an experimental hypervisor plugin. For implementation details, read CloudStack 101 on the wiki, see how plugins are written and follow the LXC plugin implementation or see this commit: https://github.com/apache/cloudstack/commit/c27c69438ba23386bac7ae4dd651b1d809811157 On Monday 16 March 2015 02:53 AM, Diwas Joshi wrote: hello, I would like to work on the following issue for https://issues.apache.org/jira/browse/CLOUDSTACK-8205 for google summer of code 2015. It would be really helpful if someone can tell me more about the idea and provide guidelines to get started with this. regards -- Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 8826230892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab PS. If you see any footer below, I did not add it :) Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: BUG: anybody addressing this one ?
Happened to me on several occasions as well. However, I am double careful now and I double check the volume names before deleting to make sure I do the right one. This little bug is annoying to say the least ))) Andrei - Original Message - From: Andrija Panic andrija.pa...@gmail.com To: dev@cloudstack.apache.org Sent: Wednesday, 18 March, 2015 11:58:53 AM Subject: BUG: anybody addressing this one ? Hi, https://issues.apache.org/jira/browse/CLOUDSTACK-7926 Currently I have hit a bug, when I click on some instance, then on View Volumes, and then I get listed volumes that belong to some other VM - it already happened to me that I deleted the volumes - beacuse of ACS bug in GUI ! So, I suggest to consider maybe to implement purging volumes the same way it is implemented with VM-s - so the VM is not really deleted - and the purge thread in ACS will acually delete it when it runs... -- Andrija Panić
RE: [PROPOSAL] Support management/storage traffic over VMware DVS in CloudStack deployments
+1 We have had a few customers ask for this. It would have been our preferred configuration in our lab, had it been possible. Regards Paul Angus Cloud Architect S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus paul.an...@shapeblue.com -Original Message- From: Sateesh Chodapuneedi [mailto:sateesh.chodapune...@citrix.com] Sent: 18 March 2015 04:35 To: dev@cloudstack.apache.org Subject: [PROPOSAL] Support management/storage traffic over VMware DVS in CloudStack deployments Hi, I would like to extend the existing integration of VMware DVS with Apache CloudStack by adding support for management as well as storage traffic over VMware DVS. Currently guest and public traffic are supported over VMware DVS in CloudStack deployments. There was discussion in dev mailing list earlier about the requirement to support management/storage traffic as well on VMware DVS, which can be found in [3]. Corresponding jira reference is [2]. Please review FS at [1] and let me know your comments. Regards, Sateesh [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Support+Management+and+Storage+traffic+over+VMware+DVS+in+CloudStack [2] https://issues.apache.org/jira/browse/CLOUDSTACK-3317 [3] http://markmail.org/message/sz7xudwqod44awlf#query:+page:1+mid:7t2quwaxzycatfey+state:results Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
RE: Guidelines for test developers
Thank you Gaurav, It would great if the community developers could please express their support for these guidelines (or start a conversation if you feel differently). This way, this initiative will get traction. @Gaurav, are these guidelines in the developer section of the CloudStack wiki? Regards Paul Angus Cloud Architect S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus paul.an...@shapeblue.com -Original Message- From: Gaurav Aradhye [mailto:gaurav.arad...@clogeny.com] Sent: 18 March 2015 07:16 To: dev@cloudstack.apache.org Subject: Guidelines for test developers Hello all, Last year after improving Marvin framework, we have been continuously spending time in improving old test cases which are written in old style or they don't abide to certain guidelines, also which don't use new functions available in marvin. Many times a test developer who is adding test case for the first time or feature developers adding Basic Validation Tests (BVTs) tend to copy paste the code available in certain test case and try to modify it according to feature and commit it. This adds to inconsistencies. As and when I touch a file for fixing an issue or adding/editing it, I try to incorporate below guidelines and improve the existing code. But still few test files are not up to the mark. Our final goal is to have good code in every file.So writing this mail to consolidate few rules that should be known/considered by everyone adding tests to Marvin. Also, if you touch a file, feel free to remove any inconsistencies that are already present in the file. *1. Import * should always be avoided*. When I started two years back, and tried to understand the code flow/ test cases, I could not easily understand from where the particular module is imported. The imports must be specific. When the imports are specific, it eliminates the possibility of test case failure due to invalid import when specific import is removed from dependent module. E.g. If your test case has following import. from A import * And it uses time module which is not imported explicitly in test case and comes from module A. Then the test case will start failing when import timeis removed from module A. You certainly don't want this to happen. *2. Maintaining Pep8 standards for python code.* The code is read more often that it is written. Pep8 standards improve the readability of the code making it consistent in style. There is a tool named *autopep8* which you can install with pip install and then you can run following command on your test file. autopep8 -i -a -a testFile.py This will make the file pep8 consistent and will also remove the white spaces. But some issues need human intervention and can't be fixed with tool. For fixing those, check the pep8 issues with pep8 testFile.py and fix manually. *3. Keep only imports which are used* in the test suite and remove unwanted imports. *4. Keep all the configuration parameters* (such as data which is passed to API while creating Network offering, Service offering, account etc...) *in tools/marvin/marvin/config/test_data.py file*. Don't include them in test suite itself. Many of the dictionaries are reusable and if you are adding a new test, there are only a few dictionaries you will have to add in the file. If any of the data contains URLs or any data which should be changed according to setup/env, then include the dict in *configurableData* section in test_data.py file. This makes it easier to identify which data needs to be dynamic according to the setup and which data doesn't need to be touched when env is changed. *5. Before committing a test case, run it* with the latest branch against which you are adding the test case and attach the results in Pull Request. If in case change is very small, and doesn't need to be run, then at least check syntactical errors with python command and also with the help of tools such as pyflakes. 6. If you add a new function in your test case and you think it can be used in future by other test cases, then please *add that function to common or utils file* in Marvin. Don't keep it local to test case. This will prevent multiple contributors adding same functions in their test case to achieve a particular goal. *7. Please make sure all the resources created through the test cases are deleted *when test case execution completes, or even when the test case fails. 8. If same test case is to be run with different configuration or setting, you can *make use of ddt library*. For example, if you have added test case for isolated networks, and you need to run the same code for shared and VPC networks, then you don't need to add 3 test cases. Just add relevant tags to the test case and you are good to go. Although you will need to write code for handling those tags. It is already used in few test cases. A simple grep over component folder and you can see how it is used. This blog explains how it works.
BUG: anybody addressing this one ?
Hi, https://issues.apache.org/jira/browse/CLOUDSTACK-7926 Currently I have hit a bug, when I click on some instance, then on View Volumes, and then I get listed volumes that belong to some other VM - it already happened to me that I deleted the volumes - beacuse of ACS bug in GUI ! So, I suggest to consider maybe to implement purging volumes the same way it is implemented with VM-s - so the VM is not really deleted - and the purge thread in ACS will acually delete it when it runs... -- Andrija Panić
Re: Let's start 4.5.1 release process?
+1 We should have done this the next day after 4.5. :-) -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Rohit Yadav rohit.ya...@shapeblue.com To: dev dev@cloudstack.apache.org, David Nalley da...@gnsa.us Sent: Wednesday, 18 March, 2015 09:18:04 Subject: Let's start 4.5.1 release process? Hi all, I've been testing and fixing issues in the past weeks on 4.5. I think 4.5 is in a better state and we've upgrade paths from 4.5.0 to 4.5.1 and 4.5.1 to 4.6.0 (master) as well. Has anyone found any blockers or issues that should be addressed on 4.5? David - If we're all good, let's cut a RC soon and release 4.5.1? Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 8826230892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab PS. If you see any footer below, I did not add it :) Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
BUG: Hide shared networks with no free IP, from GUI in Add network to VM dialog
Hi, just filed the new bug: https://issues.apache.org/jira/browse/CLOUDSTACK-8333 Nothing critical, but should be fixes (if not done already in newer releases) When all IPs are consumed (no more IPs available) in the Shared Guest network then folowing is true in 4.3.2 - In the Add Instance wizard, this Guest netowrk is NOT displayed any more - FINE. - When editing existng VM, on the NIC tab, when clicking Add network to VM this Guest network IS available - and this results with an error since no free IPs in the pool. For consistency reasons, the network should also not be displayed in the Add network to VM dialog/popup. -- Andrija Panić
Build failed in Jenkins: build-master-slowbuild #1130
See http://jenkins.buildacloud.org/job/build-master-slowbuild/1130/ -- [...truncated 23731 lines...] [INFO] [INFO] --- cobertura-maven-plugin:2.7:cobertura (default-cli) @ cloud-awsapi --- [INFO] Cobertura 2.1.1 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file [INFO] Cobertura: Loaded information on 6393 classes. [INFO] Data file does not contain instrumentation information for the file com/amazon/ec2/AmazonEC2SkeletonInterface.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/amazon/s3/AmazonS3SkeletonInterface.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/model/SAcl.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/model/SBucket.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/model/SHost.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/BucketPolicyDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/CloudStackAccountDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/CloudStackConfigurationDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/CloudStackSvcOfferingDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/CloudStackUserDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MHostDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MHostMountDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MultiPartPartsDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MultiPartUploadsDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MultipartMetaDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/OfferingDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/SAclDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/SBucketDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/SHostDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/SMetaDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/SObjectDao.java. Ensure this class was instrumented, and this data
Re: Guidelines for test developers
good write-up Gaurav, I hope that most of these can be validated/verified checkstyle-style. pep8 can of course. Some others must remain judged by humanoids, like the one where functions are pulled up to higher abstraction layers. Maybe you could shine your light on what we can automate? i.e. can pyflakes be added to a target? -Original Message- From: Gaurav Aradhye [mailto:gaurav.arad...@clogeny.com] Sent: 18 March 2015 07:16 To: dev@cloudstack.apache.org Subject: Guidelines for test developers Hello all, Last year after improving Marvin framework, we have been continuously spending time in improving old test cases which are written in old style or they don't abide to certain guidelines, also which don't use new functions available in marvin. Many times a test developer who is adding test case for the first time or feature developers adding Basic Validation Tests (BVTs) tend to copy paste the code available in certain test case and try to modify it according to feature and commit it. This adds to inconsistencies. As and when I touch a file for fixing an issue or adding/editing it, I try to incorporate below guidelines and improve the existing code. But still few test files are not up to the mark. Our final goal is to have good code in every file.So writing this mail to consolidate few rules that should be known/considered by everyone adding tests to Marvin. Also, if you touch a file, feel free to remove any inconsistencies that are already present in the file. *1. Import * should always be avoided*. When I started two years back, and tried to understand the code flow/ test cases, I could not easily understand from where the particular module is imported. The imports must be specific. When the imports are specific, it eliminates the possibility of test case failure due to invalid import when specific import is removed from dependent module. E.g. If your test case has following import. from A import * And it uses time module which is not imported explicitly in test case and comes from module A. Then the test case will start failing when import timeis removed from module A. You certainly don't want this to happen. *2. Maintaining Pep8 standards for python code.* The code is read more often that it is written. Pep8 standards improve the readability of the code making it consistent in style. There is a tool named *autopep8* which you can install with pip install and then you can run following command on your test file. autopep8 -i -a -a testFile.py This will make the file pep8 consistent and will also remove the white spaces. But some issues need human intervention and can't be fixed with tool. For fixing those, check the pep8 issues with pep8 testFile.py and fix manually. *3. Keep only imports which are used* in the test suite and remove unwanted imports. *4. Keep all the configuration parameters* (such as data which is passed to API while creating Network offering, Service offering, account etc...) *in tools/marvin/marvin/config/test_data.py file*. Don't include them in test suite itself. Many of the dictionaries are reusable and if you are adding a new test, there are only a few dictionaries you will have to add in the file. If any of the data contains URLs or any data which should be changed according to setup/env, then include the dict in *configurableData* section in test_data.py file. This makes it easier to identify which data needs to be dynamic according to the setup and which data doesn't need to be touched when env is changed. *5. Before committing a test case, run it* with the latest branch against which you are adding the test case and attach the results in Pull Request. If in case change is very small, and doesn't need to be run, then at least check syntactical errors with python command and also with the help of tools such as pyflakes. 6. If you add a new function in your test case and you think it can be used in future by other test cases, then please *add that function to common or utils file* in Marvin. Don't keep it local to test case. This will prevent multiple contributors adding same functions in their test case to achieve a particular goal. *7. Please make sure all the resources created through the test cases are deleted *when test case execution completes, or even when the test case fails. 8. If same test case is to be run with different configuration or setting, you can *make use of ddt library*. For example, if you have added test case for isolated networks, and you need to run the same code for shared and VPC networks, then you don't need to add 3 test cases. Just add relevant tags to the test case and you are good to go. Although you will need to write code for handling those tags. It is already used in few test cases. A simple grep over component folder and you can see how it is used. This blog explains how it works.
Re: BUG: anybody addressing this one ?
Andrei, please comment the JIRA with same text if you have time :) otherwise...no use here I guess Thanks On 18 March 2015 at 14:26, Andrei Mikhailovsky and...@arhont.com wrote: Happened to me on several occasions as well. However, I am double careful now and I double check the volume names before deleting to make sure I do the right one. This little bug is annoying to say the least ))) Andrei - Original Message - From: Andrija Panic andrija.pa...@gmail.com To: dev@cloudstack.apache.org Sent: Wednesday, 18 March, 2015 11:58:53 AM Subject: BUG: anybody addressing this one ? Hi, https://issues.apache.org/jira/browse/CLOUDSTACK-7926 Currently I have hit a bug, when I click on some instance, then on View Volumes, and then I get listed volumes that belong to some other VM - it already happened to me that I deleted the volumes - beacuse of ACS bug in GUI ! So, I suggest to consider maybe to implement purging volumes the same way it is implemented with VM-s - so the VM is not really deleted - and the purge thread in ACS will acually delete it when it runs... -- Andrija Panić -- Andrija Panić
Re: Root disk size support in UI - problem with instanceWizard.js
Hey Nux, This is completely untested and based of reading the source code. Within ui/scripts/ui-custom/instanceWizard.js on line ~ 424 you should find a call to the custom hidden function which determines whether or not to set display = none on the root resize box. Within the ui/scripts/instanceWizard.js you'll see that the root resize is applied if its element isn't set to display none. I'd suggest just setting var custom = false; as a quick and easy fix. https://github.com/apache/cloudstack/blob/master/ui/scripts/ui-custom/instanceWizard.js#L424-437 On 18 March 2015 at 16:25, Nux! n...@li.nux.ro wrote: Hello, In my 4.4.1 install I can use this patch[1] to specify a custom root disk size for an instance[2]. This is of course very handy, enabled me to get rid of tens of templates with custom sizes. In 4.5 this patch no longer does it's job, there is no Root Disk field appearing during instance creation. Can anyone have a look? [1] https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=ui/scripts/instanceWizard.js;h=4a740c6685e05449290f1fe378add9a6c71f96ad;hp=646ffbf5b1922fc618bb3ad0091fe15895c24226;hb=8fec09ba481fbd3b8c2a9e4d31ef06f113b037cb;hpb=c1af92fcbbc183873d6519f0660b68acfb33bd44 [2] http://img.nux.ro/Fw3-Selection_020.png - This is a KVM only feature for now -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Root disk size support in UI - problem with instanceWizard.js
Hello, In my 4.4.1 install I can use this patch[1] to specify a custom root disk size for an instance[2]. This is of course very handy, enabled me to get rid of tens of templates with custom sizes. In 4.5 this patch no longer does it's job, there is no Root Disk field appearing during instance creation. Can anyone have a look? [1] https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=ui/scripts/instanceWizard.js;h=4a740c6685e05449290f1fe378add9a6c71f96ad;hp=646ffbf5b1922fc618bb3ad0091fe15895c24226;hb=8fec09ba481fbd3b8c2a9e4d31ef06f113b037cb;hpb=c1af92fcbbc183873d6519f0660b68acfb33bd44 [2] http://img.nux.ro/Fw3-Selection_020.png - This is a KVM only feature for now -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Re: junkins
Daan, On 17 Mar 2015, at 12:23, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: Laszlo, I don't think anyone is working on this. Jenkins output is largely ignored in this community. The fact that the present cause is a resource problem is worrying. I think these are SBP hosted slaves and will have a look (not in the office now). If I fix this the slowbuild will not work at least. The last time I saw it passing by it had 6 new unattended issues from the findbugs output. Coverity complained about new issues as well, i noticed just now. Do I have access to these boxes? Quite happy to have a look. — Ian
Build failed in Jenkins: build-master-slowbuild #1131
See http://jenkins.buildacloud.org/job/build-master-slowbuild/1131/ -- [...truncated 87799 lines...] [INFO] [INFO] --- cobertura-maven-plugin:2.7:cobertura (default-cli) @ cloud-awsapi --- [INFO] Cobertura 2.1.1 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file [INFO] Cobertura: Loaded information on 6393 classes. [INFO] Data file does not contain instrumentation information for the file com/amazon/ec2/AmazonEC2SkeletonInterface.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/amazon/s3/AmazonS3SkeletonInterface.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/model/SAcl.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/model/SBucket.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/model/SHost.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/BucketPolicyDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/CloudStackAccountDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/CloudStackConfigurationDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/CloudStackSvcOfferingDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/CloudStackUserDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MHostDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MHostMountDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MultiPartPartsDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MultiPartUploadsDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/MultipartMetaDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/OfferingDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/SAclDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/SBucketDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/SHostDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/SMetaDao.java. Ensure this class was instrumented, and this data file contains the instrumentation information. [INFO] Data file does not contain instrumentation information for the file com/cloud/bridge/persist/dao/SObjectDao.java. Ensure this class was instrumented, and this data
Re: BUG: anybody addressing this one ?
Just done. As i've commented in the bug report, similar behaviour happens when you go to Infrastructure Hosts host View Instances. Sometimes you get a list of all instances, even the stopped instances, instead of only those that run on the chosen host. Andrei - Original Message - From: Andrija Panic andrija.pa...@gmail.com To: dev@cloudstack.apache.org Sent: Wednesday, 18 March, 2015 1:58:35 PM Subject: Re: BUG: anybody addressing this one ? Andrei, please comment the JIRA with same text if you have time :) otherwise...no use here I guess Thanks On 18 March 2015 at 14:26, Andrei Mikhailovsky and...@arhont.com wrote: Happened to me on several occasions as well. However, I am double careful now and I double check the volume names before deleting to make sure I do the right one. This little bug is annoying to say the least ))) Andrei - Original Message - From: Andrija Panic andrija.pa...@gmail.com To: dev@cloudstack.apache.org Sent: Wednesday, 18 March, 2015 11:58:53 AM Subject: BUG: anybody addressing this one ? Hi, https://issues.apache.org/jira/browse/CLOUDSTACK-7926 Currently I have hit a bug, when I click on some instance, then on View Volumes, and then I get listed volumes that belong to some other VM - it already happened to me that I deleted the volumes - beacuse of ACS bug in GUI ! So, I suggest to consider maybe to implement purging volumes the same way it is implemented with VM-s - so the VM is not really deleted - and the purge thread in ACS will acually delete it when it runs... -- Andrija Panić -- Andrija Panić
Re: Root disk size support in UI - problem with instanceWizard.js
for 4.5, you'll need to gzip any js files after editing them. At least that's what I've observed. You should see a .js and a .js.gz for each. On Wed, Mar 18, 2015 at 11:44 AM, Nux! n...@li.nux.ro wrote: Thanks Ian, tried your suggestions, but to no effect that I can observe. The root disk field does not appear on the instance creation page. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Ian Duffy i...@ianduffy.ie To: CloudStack Dev dev@cloudstack.apache.org Sent: Wednesday, 18 March, 2015 16:52:30 Subject: Re: Root disk size support in UI - problem with instanceWizard.js Hey Nux, This is completely untested and based of reading the source code. Within ui/scripts/ui-custom/instanceWizard.js on line ~ 424 you should find a call to the custom hidden function which determines whether or not to set display = none on the root resize box. Within the ui/scripts/instanceWizard.js you'll see that the root resize is applied if its element isn't set to display none. I'd suggest just setting var custom = false; as a quick and easy fix. https://github.com/apache/cloudstack/blob/master/ui/scripts/ui-custom/instanceWizard.js#L424-437 On 18 March 2015 at 16:25, Nux! n...@li.nux.ro wrote: Hello, In my 4.4.1 install I can use this patch[1] to specify a custom root disk size for an instance[2]. This is of course very handy, enabled me to get rid of tens of templates with custom sizes. In 4.5 this patch no longer does it's job, there is no Root Disk field appearing during instance creation. Can anyone have a look? [1] https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=ui/scripts/instanceWizard.js;h=4a740c6685e05449290f1fe378add9a6c71f96ad;hp=646ffbf5b1922fc618bb3ad0091fe15895c24226;hb=8fec09ba481fbd3b8c2a9e4d31ef06f113b037cb;hpb=c1af92fcbbc183873d6519f0660b68acfb33bd44 [2] http://img.nux.ro/Fw3-Selection_020.png - This is a KVM only feature for now -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Guidelines for test developers
Hello all, Last year after improving Marvin framework, we have been continuously spending time in improving old test cases which are written in old style or they don't abide to certain guidelines, also which don't use new functions available in marvin. Many times a test developer who is adding test case for the first time or feature developers adding Basic Validation Tests (BVTs) tend to copy paste the code available in certain test case and try to modify it according to feature and commit it. This adds to inconsistencies. As and when I touch a file for fixing an issue or adding/editing it, I try to incorporate below guidelines and improve the existing code. But still few test files are not up to the mark. Our final goal is to have good code in every file.So writing this mail to consolidate few rules that should be known/considered by everyone adding tests to Marvin. Also, if you touch a file, feel free to remove any inconsistencies that are already present in the file. *1. Import * should always be avoided*. When I started two years back, and tried to understand the code flow/ test cases, I could not easily understand from where the particular module is imported. The imports must be specific. When the imports are specific, it eliminates the possibility of test case failure due to invalid import when specific import is removed from dependent module. E.g. If your test case has following import. from A import * And it uses time module which is not imported explicitly in test case and comes from module A. Then the test case will start failing when import timeis removed from module A. You certainly don't want this to happen. *2. Maintaining Pep8 standards for python code.* The code is read more often that it is written. Pep8 standards improve the readability of the code making it consistent in style. There is a tool named *autopep8* which you can install with pip install and then you can run following command on your test file. autopep8 -i -a -a testFile.py This will make the file pep8 consistent and will also remove the white spaces. But some issues need human intervention and can't be fixed with tool. For fixing those, check the pep8 issues with pep8 testFile.py and fix manually. *3. Keep only imports which are used* in the test suite and remove unwanted imports. *4. Keep all the configuration parameters* (such as data which is passed to API while creating Network offering, Service offering, account etc...) *in tools/marvin/marvin/config/test_data.py file*. Don't include them in test suite itself. Many of the dictionaries are reusable and if you are adding a new test, there are only a few dictionaries you will have to add in the file. If any of the data contains URLs or any data which should be changed according to setup/env, then include the dict in *configurableData* section in test_data.py file. This makes it easier to identify which data needs to be dynamic according to the setup and which data doesn't need to be touched when env is changed. *5. Before committing a test case, run it* with the latest branch against which you are adding the test case and attach the results in Pull Request. If in case change is very small, and doesn't need to be run, then at least check syntactical errors with python command and also with the help of tools such as pyflakes. 6. If you add a new function in your test case and you think it can be used in future by other test cases, then please *add that function to common or utils file* in Marvin. Don't keep it local to test case. This will prevent multiple contributors adding same functions in their test case to achieve a particular goal. *7. Please make sure all the resources created through the test cases are deleted *when test case execution completes, or even when the test case fails. 8. If same test case is to be run with different configuration or setting, you can *make use of ddt library*. For example, if you have added test case for isolated networks, and you need to run the same code for shared and VPC networks, then you don't need to add 3 test cases. Just add relevant tags to the test case and you are good to go. Although you will need to write code for handling those tags. It is already used in few test cases. A simple grep over component folder and you can see how it is used. This blog explains how it works. https://technomilk.wordpress.com/2012/02/12/multiplying-python-unit-test-cases-with-different-sets-of-data/ I will check if this is in any wiki page currently, and edit it. Or will add a new page. I hope everyone adding test cases follows above guidelines. Feel free to add more. Regards, Gaurav
Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205)
+1 Pierre and Sebastien. We should make sure CoreOS co run fine on ACS, then let people do their thing using specific tools. Plus I wouldn't like Docker to run straight on shared bare metal servers (hypervisors), they're not as secure as VMs. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Pierre-Luc Dion pd...@cloudops.com To: dev@cloudstack.apache.org Sent: Thursday, 19 March, 2015 00:39:43 Subject: Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205) I really like Sebastien concept of Container as workload because it could be used into an existing cloud without introducing a new hypervisor, also, it might be possible to reuse current networking features of cloudstack. On Wed, Mar 18, 2015 at 6:35 AM, Sebastien Goasguen run...@gmail.com wrote: On Mar 18, 2015, at 10:43 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Diwas, The idea is to support Docker in ACS, much like LXC since they are similar (containers). This of course would have some limitations wrt supporting various network models and disk operations such as taking snapshot and migrations across hosts. ((Btw, you may also consider supporting Bhyve (VMM from FreeBSD community) in CloudStack using libvirt which is another interesting project.)) Irrespective of what base OS (RancherOS, CoreOS or Atomic etc) will be, assume it will be at least Linux 3.16. Assume using barebone technologies instead of relying on other orchestration or high level systems to control Docker images unless what you're willing to use are stable enough. While it's an open discussion on what the scope or the best way to do it; IMO, the basic things I'm looking for are: - Support Basic networking (supporting at least Linux bridge or maybe OVS - I'm not sure the best way to do it) - SystemVMs can be Docker based or VMs running on KVM - Local or NFS based shared storage. Support basic operations such as - upload/register template, create VMs using template. - Console proxy support (if possible). Since most players in the docker arena are still figuring out best way to deal with networking and storage, the expectation of the work is limited to producing an experimental hypervisor plugin. For implementation details, read CloudStack 101 on the wiki, see how plugins are written and follow the LXC plugin implementation or see this commit: https://github.com/apache/cloudstack/commit/c27c69438ba23386bac7ae4dd651b1d809811157 I understand why we you would like to do this, however I see Docker as a ‘workload’. It is easy to setup in a VM or bare metal. The Docker ecosystem is booming and there are a ton of Docker “orchestrator” being worked on. It seems to me it will be very difficult to keep up development of a proper docker management service in CloudStack. Personally, I’d rather see us put efforts in properly supporting all the new Docker customized OS (making cloudstack templates for them), fixing our cloudinit support and extending our API to create clusters of machines. That way it will be easy for CloudStack users to start a Docker cluster and use their docker container orchestrator of choice. Very much like if you want to deploy Mesos or the like in CloudStack, Docker orchestrators are really workloads in our clouds. Our strategy for Docker support should be to make it extremely easy for folks to use Docker in CloudStack VMs. Do things like Docker machine support, Docker swarm support etc….and if we want a tighter integration we should look at the AWS ECS API and the GCE container engine API and extend our EC2/GCE bridges to support them. my 2 cts. On Monday 16 March 2015 02:53 AM, Diwas Joshi wrote: hello, I would like to work on the following issue for https://issues.apache.org/jira/browse/CLOUDSTACK-8205 for google summer of code 2015. It would be really helpful if someone can tell me more about the idea and provide guidelines to get started with this. regards -- Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 8826230892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab PS. If you see any footer below, I did not add it :) Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Build http://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineering http://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Support http://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courses http://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the
Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205)
I really like Sebastien concept of Container as workload because it could be used into an existing cloud without introducing a new hypervisor, also, it might be possible to reuse current networking features of cloudstack. On Wed, Mar 18, 2015 at 6:35 AM, Sebastien Goasguen run...@gmail.com wrote: On Mar 18, 2015, at 10:43 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Diwas, The idea is to support Docker in ACS, much like LXC since they are similar (containers). This of course would have some limitations wrt supporting various network models and disk operations such as taking snapshot and migrations across hosts. ((Btw, you may also consider supporting Bhyve (VMM from FreeBSD community) in CloudStack using libvirt which is another interesting project.)) Irrespective of what base OS (RancherOS, CoreOS or Atomic etc) will be, assume it will be at least Linux 3.16. Assume using barebone technologies instead of relying on other orchestration or high level systems to control Docker images unless what you're willing to use are stable enough. While it's an open discussion on what the scope or the best way to do it; IMO, the basic things I'm looking for are: - Support Basic networking (supporting at least Linux bridge or maybe OVS - I'm not sure the best way to do it) - SystemVMs can be Docker based or VMs running on KVM - Local or NFS based shared storage. Support basic operations such as - upload/register template, create VMs using template. - Console proxy support (if possible). Since most players in the docker arena are still figuring out best way to deal with networking and storage, the expectation of the work is limited to producing an experimental hypervisor plugin. For implementation details, read CloudStack 101 on the wiki, see how plugins are written and follow the LXC plugin implementation or see this commit: https://github.com/apache/cloudstack/commit/c27c69438ba23386bac7ae4dd651b1d809811157 I understand why we you would like to do this, however I see Docker as a ‘workload’. It is easy to setup in a VM or bare metal. The Docker ecosystem is booming and there are a ton of Docker “orchestrator” being worked on. It seems to me it will be very difficult to keep up development of a proper docker management service in CloudStack. Personally, I’d rather see us put efforts in properly supporting all the new Docker customized OS (making cloudstack templates for them), fixing our cloudinit support and extending our API to create clusters of machines. That way it will be easy for CloudStack users to start a Docker cluster and use their docker container orchestrator of choice. Very much like if you want to deploy Mesos or the like in CloudStack, Docker orchestrators are really workloads in our clouds. Our strategy for Docker support should be to make it extremely easy for folks to use Docker in CloudStack VMs. Do things like Docker machine support, Docker swarm support etc….and if we want a tighter integration we should look at the AWS ECS API and the GCE container engine API and extend our EC2/GCE bridges to support them. my 2 cts. On Monday 16 March 2015 02:53 AM, Diwas Joshi wrote: hello, I would like to work on the following issue for https://issues.apache.org/jira/browse/CLOUDSTACK-8205 for google summer of code 2015. It would be really helpful if someone can tell me more about the idea and provide guidelines to get started with this. regards -- Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 8826230892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab PS. If you see any footer below, I did not add it :) Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Build http://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineering http://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Support http://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courses http://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue
Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205)
Now, CloudStack supports running CoreOS on XS, KVM, Hyper-V, VMware, bellow as: https://coreos.com/docs/running-coreos/platforms/cloudstack/ http://dl.openvm.eu/cloudstack/coreos/x86_64/ Best Regards, Star Guo -邮件原件- 发件人: Nux! [mailto:n...@li.nux.ro] 发送时间: 2015年3月19日 8:51 收件人: dev@cloudstack.apache.org 主题: Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205) +1 Pierre and Sebastien. We should make sure CoreOS co run fine on ACS, then let people do their thing using specific tools. Plus I wouldn't like Docker to run straight on shared bare metal servers (hypervisors), they're not as secure as VMs. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Pierre-Luc Dion pd...@cloudops.com To: dev@cloudstack.apache.org Sent: Thursday, 19 March, 2015 00:39:43 Subject: Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205) I really like Sebastien concept of Container as workload because it could be used into an existing cloud without introducing a new hypervisor, also, it might be possible to reuse current networking features of cloudstack. On Wed, Mar 18, 2015 at 6:35 AM, Sebastien Goasguen run...@gmail.com wrote: On Mar 18, 2015, at 10:43 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Diwas, The idea is to support Docker in ACS, much like LXC since they are similar (containers). This of course would have some limitations wrt supporting various network models and disk operations such as taking snapshot and migrations across hosts. ((Btw, you may also consider supporting Bhyve (VMM from FreeBSD community) in CloudStack using libvirt which is another interesting project.)) Irrespective of what base OS (RancherOS, CoreOS or Atomic etc) will be, assume it will be at least Linux 3.16. Assume using barebone technologies instead of relying on other orchestration or high level systems to control Docker images unless what you're willing to use are stable enough. While it's an open discussion on what the scope or the best way to do it; IMO, the basic things I'm looking for are: - Support Basic networking (supporting at least Linux bridge or maybe OVS - I'm not sure the best way to do it) - SystemVMs can be Docker based or VMs running on KVM - Local or NFS based shared storage. Support basic operations such as - upload/register template, create VMs using template. - Console proxy support (if possible). Since most players in the docker arena are still figuring out best way to deal with networking and storage, the expectation of the work is limited to producing an experimental hypervisor plugin. For implementation details, read CloudStack 101 on the wiki, see how plugins are written and follow the LXC plugin implementation or see this commit: https://github.com/apache/cloudstack/commit/c27c69438ba23386bac7ae4dd 651b1d809811157 I understand why we you would like to do this, however I see Docker as a ‘workload’. It is easy to setup in a VM or bare metal. The Docker ecosystem is booming and there are a ton of Docker “orchestrator” being worked on. It seems to me it will be very difficult to keep up development of a proper docker management service in CloudStack. Personally, I’d rather see us put efforts in properly supporting all the new Docker customized OS (making cloudstack templates for them), fixing our cloudinit support and extending our API to create clusters of machines. That way it will be easy for CloudStack users to start a Docker cluster and use their docker container orchestrator of choice. Very much like if you want to deploy Mesos or the like in CloudStack, Docker orchestrators are really workloads in our clouds. Our strategy for Docker support should be to make it extremely easy for folks to use Docker in CloudStack VMs. Do things like Docker machine support, Docker swarm support etc….and if we want a tighter integration we should look at the AWS ECS API and the GCE container engine API and extend our EC2/GCE bridges to support them. my 2 cts. On Monday 16 March 2015 02:53 AM, Diwas Joshi wrote: hello, I would like to work on the following issue for https://issues.apache.org/jira/browse/CLOUDSTACK-8205 for google summer of code 2015. It would be really helpful if someone can tell me more about the idea and provide guidelines to get started with this. regards -- Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 8826230892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab PS. If you see any footer below, I did not add it :) Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Build http://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment
Require write/edit access to Cloudstack wiki
I would like to add a page to wiki stating Guidelines for test developers. Can somebody give me access? My username is aradhye.gaurav Regards, Gaurav
Re: Review Request 27611: CLOUDSTACK-6282 - Added automated tests for filter feature
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27611/#review77011 --- test/integration/component/test_escalations_ipaddresses.py https://reviews.apache.org/r/27611/#comment124768 Please remove white-spaces. test/integration/component/test_escalations_vpncustomergateways.py https://reviews.apache.org/r/27611/#comment124772 Please fix pep8 issues - Gaurav Aradhye On March 19, 2015, 10:38 a.m., Avinash Gautam wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27611/ --- (Updated March 19, 2015, 10:38 a.m.) Review request for cloudstack and Santhosh Edukulla. Bugs: CLOUDSTACK-6282 https://issues.apache.org/jira/browse/CLOUDSTACK-6282 Repository: cloudstack-git Description --- CLOUDSTACK-6282 - Added automated tests for filter feature Diffs - test/integration/component/test_escalations_ipaddresses.py c60c5b6 test/integration/component/test_escalations_isos.py 4e818a5 test/integration/component/test_escalations_networks.py fb2196c test/integration/component/test_escalations_volumes.py 58f5845 test/integration/component/test_escalations_vpncustomergateways.py b09930a Diff: https://reviews.apache.org/r/27611/diff/ Testing --- Tested all the files to which tests are added and atatched are the result files File Attachments IPAddressresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/3b21a80f-2917-4650-a9ca-3e213afb26fc__IPAddressresults.txt ISOresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/2cd44d83-e7e5-47be-9c80-03d9a2f4f710__ISOresults.txt Networksresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/7661c962-f561-4e83-8b37-bc6676bc6808__Networksresults.txt SecurityGroupsresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/2a2d8465-2f58-4049-ad93-f878c33d5faa__SecurityGroupsresults.txt Snapshotresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/63ba74be-bc72-4419-8b7b-1fa788275be2__Snapshotresults.txt Templatesresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/c51e1861-7137-4186-82c8-7e3c85a31905__Templatesresults.txt Volumeresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/f1a11419-aa10-48e0-8291-ceb762d4a734__Volumeresults.txt VPNCustomerGatewaysresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/4c8d2447-016e-49c0-9db2-b255625cd33f__VPNCustomerGatewaysresults.txt Thanks, Avinash Gautam
Re: Review Request 27611: CLOUDSTACK-6282 - Added automated tests for filter feature
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27611/ --- (Updated March 19, 2015, 5:52 a.m.) Review request for cloudstack and Santhosh Edukulla. Changes --- Modified tests and incorporated changes. Bugs: CLOUDSTACK-6282 https://issues.apache.org/jira/browse/CLOUDSTACK-6282 Repository: cloudstack-git Description --- CLOUDSTACK-6282 - Added automated tests for filter feature Diffs (updated) - test/integration/component/test_escalations_ipaddresses.py c60c5b6 test/integration/component/test_escalations_vpncustomergateways.py b09930a Diff: https://reviews.apache.org/r/27611/diff/ Testing --- Tested all the files to which tests are added and atatched are the result files File Attachments IPAddressresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/3b21a80f-2917-4650-a9ca-3e213afb26fc__IPAddressresults.txt ISOresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/2cd44d83-e7e5-47be-9c80-03d9a2f4f710__ISOresults.txt Networksresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/7661c962-f561-4e83-8b37-bc6676bc6808__Networksresults.txt SecurityGroupsresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/2a2d8465-2f58-4049-ad93-f878c33d5faa__SecurityGroupsresults.txt Snapshotresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/63ba74be-bc72-4419-8b7b-1fa788275be2__Snapshotresults.txt Templatesresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/c51e1861-7137-4186-82c8-7e3c85a31905__Templatesresults.txt Volumeresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/f1a11419-aa10-48e0-8291-ceb762d4a734__Volumeresults.txt VPNCustomerGatewaysresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/4c8d2447-016e-49c0-9db2-b255625cd33f__VPNCustomerGatewaysresults.txt Thanks, Avinash Gautam
Re: junkins
I've fixed the slave msaz-slave-01 so it can build centos7 rpms and add the label cloudstack-buildslave-centos6 to coohq-slave-01. coohq-slave-01 run Ubuntu 14.04 I hope it does not affect something. some build jobs are back to green. On Wed, Mar 18, 2015 at 11:53 AM, Ian Southam isout...@schubergphilis.com wrote: Daan, On 17 Mar 2015, at 12:23, Daan Hoogland daan.hoogl...@gmail.commailto: daan.hoogl...@gmail.com wrote: Laszlo, I don't think anyone is working on this. Jenkins output is largely ignored in this community. The fact that the present cause is a resource problem is worrying. I think these are SBP hosted slaves and will have a look (not in the office now). If I fix this the slowbuild will not work at least. The last time I saw it passing by it had 6 new unattended issues from the findbugs output. Coverity complained about new issues as well, i noticed just now. Do I have access to these boxes? Quite happy to have a look. — Ian
Jenkins build is back to normal : build-4.5 #406
See http://jenkins.buildacloud.org/job/build-4.5/406/
Jenkins build is back to normal : build-4.5-simulator #226
See http://jenkins.buildacloud.org/job/build-4.5-simulator/226/changes
Jenkins build is back to normal : build-4.5-noredist #225
See http://jenkins.buildacloud.org/job/build-4.5-noredist/225/changes
Re: Guidelines for test developers
Paul, Some pages on wiki talk about general guidelines to Dev, but there is no page stating detailed guidelines for test developers. I would like to add a new page in QA section for this. Will drop separate mail for write access to wiki. Daan, I will have to check on this. I will find out how we can include static analysis for tests similar to that it is in place for dev code (findbugs). Regards, Gaurav On Wed, Mar 18, 2015 at 8:22 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: good write-up Gaurav, I hope that most of these can be validated/verified checkstyle-style. pep8 can of course. Some others must remain judged by humanoids, like the one where functions are pulled up to higher abstraction layers. Maybe you could shine your light on what we can automate? i.e. can pyflakes be added to a target? -Original Message- From: Gaurav Aradhye [mailto:gaurav.arad...@clogeny.com] Sent: 18 March 2015 07:16 To: dev@cloudstack.apache.org Subject: Guidelines for test developers Hello all, Last year after improving Marvin framework, we have been continuously spending time in improving old test cases which are written in old style or they don't abide to certain guidelines, also which don't use new functions available in marvin. Many times a test developer who is adding test case for the first time or feature developers adding Basic Validation Tests (BVTs) tend to copy paste the code available in certain test case and try to modify it according to feature and commit it. This adds to inconsistencies. As and when I touch a file for fixing an issue or adding/editing it, I try to incorporate below guidelines and improve the existing code. But still few test files are not up to the mark. Our final goal is to have good code in every file.So writing this mail to consolidate few rules that should be known/considered by everyone adding tests to Marvin. Also, if you touch a file, feel free to remove any inconsistencies that are already present in the file. *1. Import * should always be avoided*. When I started two years back, and tried to understand the code flow/ test cases, I could not easily understand from where the particular module is imported. The imports must be specific. When the imports are specific, it eliminates the possibility of test case failure due to invalid import when specific import is removed from dependent module. E.g. If your test case has following import. from A import * And it uses time module which is not imported explicitly in test case and comes from module A. Then the test case will start failing when import timeis removed from module A. You certainly don't want this to happen. *2. Maintaining Pep8 standards for python code.* The code is read more often that it is written. Pep8 standards improve the readability of the code making it consistent in style. There is a tool named *autopep8* which you can install with pip install and then you can run following command on your test file. autopep8 -i -a -a testFile.py This will make the file pep8 consistent and will also remove the white spaces. But some issues need human intervention and can't be fixed with tool. For fixing those, check the pep8 issues with pep8 testFile.py and fix manually. *3. Keep only imports which are used* in the test suite and remove unwanted imports. *4. Keep all the configuration parameters* (such as data which is passed to API while creating Network offering, Service offering, account etc...) *in tools/marvin/marvin/config/test_data.py file*. Don't include them in test suite itself. Many of the dictionaries are reusable and if you are adding a new test, there are only a few dictionaries you will have to add in the file. If any of the data contains URLs or any data which should be changed according to setup/env, then include the dict in *configurableData* section in test_data.py file. This makes it easier to identify which data needs to be dynamic according to the setup and which data doesn't need to be touched when env is changed. *5. Before committing a test case, run it* with the latest branch against which you are adding the test case and attach the results in Pull Request. If in case change is very small, and doesn't need to be run, then at least check syntactical errors with python command and also with the help of tools such as pyflakes. 6. If you add a new function in your test case and you think it can be used in future by other test cases, then please *add that function to common or utils file* in Marvin. Don't keep it local to test case. This will prevent multiple contributors adding same functions in their test case to achieve a particular goal. *7. Please make sure all the resources created through the test cases are deleted *when test case execution completes, or even when the test case fails. 8. If same test case is to be run with different configuration or
Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205)
+1, I think trying to catch and keep up with all of the great tooling existing for container scheduling is a losing battle. I'm not against implementing it as a hypervisor alongside lxc, but I'm not sure how much value people will find in that compared to the other advanced and purpose-built solutions out there, and to compete with those solutions would be a lot of work if you measure by the effort in those other projects. I like the idea of focusing on making cloudstack an attractive place to host infrastructure for container environments. There have been community members having great success providing and selling container services within CloudStack infrastructure. I do fear a bit that supporting it as a hypervisor will fracture the message a bit or misdirect people away from this option, but it can be overcome. If people see value in making it a top-tier hypervisor, I'm all for that, but my first choice would be to look for integration points with existing, mature technologies. On Mar 18, 2015 5:57 PM, Nux! n...@li.nux.ro wrote: +1 Pierre and Sebastien. We should make sure CoreOS co run fine on ACS, then let people do their thing using specific tools. Plus I wouldn't like Docker to run straight on shared bare metal servers (hypervisors), they're not as secure as VMs. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Pierre-Luc Dion pd...@cloudops.com To: dev@cloudstack.apache.org Sent: Thursday, 19 March, 2015 00:39:43 Subject: Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205) I really like Sebastien concept of Container as workload because it could be used into an existing cloud without introducing a new hypervisor, also, it might be possible to reuse current networking features of cloudstack. On Wed, Mar 18, 2015 at 6:35 AM, Sebastien Goasguen run...@gmail.com wrote: On Mar 18, 2015, at 10:43 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Diwas, The idea is to support Docker in ACS, much like LXC since they are similar (containers). This of course would have some limitations wrt supporting various network models and disk operations such as taking snapshot and migrations across hosts. ((Btw, you may also consider supporting Bhyve (VMM from FreeBSD community) in CloudStack using libvirt which is another interesting project.)) Irrespective of what base OS (RancherOS, CoreOS or Atomic etc) will be, assume it will be at least Linux 3.16. Assume using barebone technologies instead of relying on other orchestration or high level systems to control Docker images unless what you're willing to use are stable enough. While it's an open discussion on what the scope or the best way to do it; IMO, the basic things I'm looking for are: - Support Basic networking (supporting at least Linux bridge or maybe OVS - I'm not sure the best way to do it) - SystemVMs can be Docker based or VMs running on KVM - Local or NFS based shared storage. Support basic operations such as - upload/register template, create VMs using template. - Console proxy support (if possible). Since most players in the docker arena are still figuring out best way to deal with networking and storage, the expectation of the work is limited to producing an experimental hypervisor plugin. For implementation details, read CloudStack 101 on the wiki, see how plugins are written and follow the LXC plugin implementation or see this commit: https://github.com/apache/cloudstack/commit/c27c69438ba23386bac7ae4dd651b1d809811157 I understand why we you would like to do this, however I see Docker as a ‘workload’. It is easy to setup in a VM or bare metal. The Docker ecosystem is booming and there are a ton of Docker “orchestrator” being worked on. It seems to me it will be very difficult to keep up development of a proper docker management service in CloudStack. Personally, I’d rather see us put efforts in properly supporting all the new Docker customized OS (making cloudstack templates for them), fixing our cloudinit support and extending our API to create clusters of machines. That way it will be easy for CloudStack users to start a Docker cluster and use their docker container orchestrator of choice. Very much like if you want to deploy Mesos or the like in CloudStack, Docker orchestrators are really workloads in our clouds. Our strategy for Docker support should be to make it extremely easy for folks to use Docker in CloudStack VMs. Do things like Docker machine support, Docker swarm support etc….and if we want a tighter integration we should look at the AWS ECS API and the GCE container engine API and extend our EC2/GCE bridges to support them. my 2 cts. On Monday 16 March 2015 02:53 AM, Diwas Joshi wrote: hello, I would
Build failed in Jenkins: build-4.5 #405
See http://jenkins.buildacloud.org/job/build-4.5/405/
--
Started by user Pierre-Luc Dion
[EnvInject] - Loading node environment variables.
Building remotely on coohq-slave-01 (cloudstack-buildslave-centos6
systemvmbuilder) in workspace http://jenkins.buildacloud.org/job/build-4.5/ws/
Cloning the remote Git repository
Cloning repository https://git-wip-us.apache.org/repos/asf/cloudstack.git
/usr/bin/git init http://jenkins.buildacloud.org/job/build-4.5/ws/ #
timeout=10
Fetching upstream changes from
https://git-wip-us.apache.org/repos/asf/cloudstack.git
/usr/bin/git --version # timeout=10
/usr/bin/git -c core.askpass=true fetch --tags --progress
https://git-wip-us.apache.org/repos/asf/cloudstack.git
+refs/heads/*:refs/remotes/origin/*
/usr/bin/git config remote.origin.url
https://git-wip-us.apache.org/repos/asf/cloudstack.git # timeout=10
/usr/bin/git config --add remote.origin.fetch
+refs/heads/*:refs/remotes/origin/* # timeout=10
/usr/bin/git config remote.origin.url
https://git-wip-us.apache.org/repos/asf/cloudstack.git # timeout=10
Fetching upstream changes from
https://git-wip-us.apache.org/repos/asf/cloudstack.git
/usr/bin/git -c core.askpass=true fetch --tags --progress
https://git-wip-us.apache.org/repos/asf/cloudstack.git
+refs/heads/*:refs/remotes/origin/*
/usr/bin/git rev-parse refs/remotes/origin/4.5^{commit} # timeout=10
/usr/bin/git rev-parse refs/remotes/origin/origin/4.5^{commit} # timeout=10
Checking out Revision b8192114767040ef4869a7e71886df5965dadb37
(refs/remotes/origin/4.5)
/usr/bin/git config core.sparsecheckout # timeout=10
/usr/bin/git checkout -f b8192114767040ef4869a7e71886df5965dadb37
/usr/bin/git rev-list b8192114767040ef4869a7e71886df5965dadb37 # timeout=10
[copy-to-slave] Copying 'settings.xml', excluding nothing, from
'file:/var/lib/jenkins/userContent/' on the master to
'http://jenkins.buildacloud.org/job/build-4.5/ws/' on 'coohq-slave-01'.
Unpacking
http://archive.apache.org/dist/maven/binaries/apache-maven-3.1.1-bin.zip to
/home/jenkins/acs/tools/hudson.tasks.Maven_MavenInstallation/maven-3.1.1 on
coohq-slave-01
[build-4.5] $
/home/jenkins/acs/tools/hudson.tasks.Maven_MavenInstallation/maven-3.1.1/bin/mvn
-s http://jenkins.buildacloud.org/job/build-4.5/ws/settings.xml
-Psystemvm,awsapi -T 2C clean test
Error: JAVA_HOME is not defined correctly.
We cannot execute /usr/lib/jvm/java-1.7.0//bin/java
Build step 'Invoke top-level Maven targets' marked build as failure
Recording test results
ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception
hudson.AbortException: No test report files were found. Configuration error?
at
hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:116)
at
hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:93)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2665)
at hudson.remoting.UserRequest.perform(UserRequest.java:121)
at hudson.remoting.UserRequest.perform(UserRequest.java:49)
at hudson.remoting.Request$2.run(Request.java:324)
at
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to coohq-slave-01(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:221)
at hudson.remoting.Channel.call(Channel.java:752)
at hudson.FilePath.act(FilePath.java:970)
at hudson.FilePath.act(FilePath.java:959)
at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:90)
at
hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120)
at
hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137)
at
hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770)
at
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734)
at hudson.model.Build$BuildExecution.post2(Build.java:183)
at
hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683)
at hudson.model.Run.execute(Run.java:1784)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
Re: Review Request 27611: CLOUDSTACK-6282 - Added automated tests for filter feature
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27611/#review77013 --- Please close the fixed issues. - Gaurav Aradhye On March 19, 2015, 10:38 a.m., Avinash Gautam wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27611/ --- (Updated March 19, 2015, 10:38 a.m.) Review request for cloudstack and Santhosh Edukulla. Bugs: CLOUDSTACK-6282 https://issues.apache.org/jira/browse/CLOUDSTACK-6282 Repository: cloudstack-git Description --- CLOUDSTACK-6282 - Added automated tests for filter feature Diffs - test/integration/component/test_escalations_ipaddresses.py c60c5b6 test/integration/component/test_escalations_isos.py 4e818a5 test/integration/component/test_escalations_networks.py fb2196c test/integration/component/test_escalations_volumes.py 58f5845 test/integration/component/test_escalations_vpncustomergateways.py b09930a Diff: https://reviews.apache.org/r/27611/diff/ Testing --- Tested all the files to which tests are added and atatched are the result files File Attachments IPAddressresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/3b21a80f-2917-4650-a9ca-3e213afb26fc__IPAddressresults.txt ISOresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/2cd44d83-e7e5-47be-9c80-03d9a2f4f710__ISOresults.txt Networksresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/7661c962-f561-4e83-8b37-bc6676bc6808__Networksresults.txt SecurityGroupsresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/2a2d8465-2f58-4049-ad93-f878c33d5faa__SecurityGroupsresults.txt Snapshotresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/63ba74be-bc72-4419-8b7b-1fa788275be2__Snapshotresults.txt Templatesresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/c51e1861-7137-4186-82c8-7e3c85a31905__Templatesresults.txt Volumeresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/f1a11419-aa10-48e0-8291-ceb762d4a734__Volumeresults.txt VPNCustomerGatewaysresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/4c8d2447-016e-49c0-9db2-b255625cd33f__VPNCustomerGatewaysresults.txt Thanks, Avinash Gautam
Build failed in Jenkins: package-rhel63-4.5 #212
See http://jenkins.buildacloud.org/job/package-rhel63-4.5/212/changes Changes: [Rohit Yadav] CLOUDSTACK-7639: make cidrlist update when updateNetworkAclItem is called [Rohit Yadav] CLOUDSTACK-7639: make cidr updation more efficient [Rohit Yadav] systemvm: avoid tcp responses with timestamp [Rohit Yadav] systemvm: correct sftp subsystem path of debian wheezy [Rohit Yadav] scripts: add ip set interface up because in CentOS7 the interface will not auto up [Rohit Yadav] CLOUDSTACK-8312: The storage usage of Primary Storage Allocated is incorrect. [Rohit Yadav] CLOUDSTACK-8304: disable snapshots from non-snapshot repositories [Rohit Yadav] systemvms: use Debian http redirector for apt repos [Rohit Yadav] api: avoid sending sensitive data in api response [Rohit Yadav] CLOUDSTACK-8315: CS API listVMSnapshot doesn't have tags ���project��� and ���projectid���. [Rohit Yadav] server: remove unused import in ImageStoreJoinDaoImpl [Rohit Yadav] Update pom and version usage to 4.5.1-SNAPSHOT [Rohit Yadav] engine: Add Upgrade path from 4.5.0 to 4.5.1 [Rohit Yadav] CLOUDSTACK-8272: Python based file-lock free password server implementation [Rohit Yadav] Fix encoding for user account label in header [Rohit Yadav] Error message exposes domain Id when deployVirtualMachine() is attempted on a shared network to which the user doesnot have access to. [Rohit Yadav] CS-20680: The user's secret key is not encrypted in the UserCredentialsVO class [Rohit Yadav] CS-19734:Session cookie is exposed to scripts. [Rohit Yadav] CS-18149: UI - no longer store sessionKey in cookie. After [Rohit Yadav] CS-17504: Weak SSL ciphers supported by the management server [Rohit Yadav] Avoid distributing private key for realhostip.com [Rohit Yadav] Avoid logging password when adding srx device [Rohit Yadav] ui: if session cookie exists, use it to set global session holder and invalidate it [Rohit Yadav] utils: use a better extended implementation of SSLSocketFactory [Rajani Karuturi] CLOUDSTACK-7348 InvalidParameter Exception while executing scale vm. [Rajani Karuturi] CLOUDSTACK-5236 : ability to identify where the user is from (ex. LDAP) [Rohit Yadav] user-authenticators: don't allow empty usernames or passwords [w.zhou] UI: Fix typo in ui/scripts/configuration.js [w.zhou] CLOUDSTACK-8329: CloudStack accepts IP ends with dot [Rajani Karuturi] Fixed build failure due to commit 843f6b16914159ea6241c6c1a0a04e9d0fefaed4 [Rohit Yadav] savepassword: use eth0's IP address, as password listens on that IP [Rohit Yadav] CLOUDSTACK-8331: savepassword should try all IPs on eth0 [Rohit Yadav] vpc_passwd_server: use the improved Python based password server [Rohit Yadav] CLOUDSTACK-8331: have savepassword try all interfaces -- [...truncated 7471 lines...] [INFO] Total time: 16:01.738s [INFO] Finished at: Wed Mar 18 23:39:28 EDT 2015 [INFO] Final Memory: 82M/286M [INFO] + exit 0 Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.IyCKPj + umask 022 + cd http://jenkins.buildacloud.org/job/package-rhel63-4.5/ws/packaging/centos63/../../dist/rpmbuild/BUILD + '[' http://jenkins.buildacloud.org/job/package-rhel63-4.5/ws/dist/rpmbuild/BUILDROOT/cloudstack-4.5.1-SNAPSHOT.el6.x86_64 '!=' / ']' + rm -rf http://jenkins.buildacloud.org/job/package-rhel63-4.5/ws/dist/rpmbuild/BUILDROOT/cloudstack-4.5.1-SNAPSHOT.el6.x86_64 ++ dirname http://jenkins.buildacloud.org/job/package-rhel63-4.5/ws/dist/rpmbuild/BUILDROOT/cloudstack-4.5.1-SNAPSHOT.el6.x86_64 + mkdir -p http://jenkins.buildacloud.org/job/package-rhel63-4.5/ws/dist/rpmbuild/BUILDROOT + mkdir http://jenkins.buildacloud.org/job/package-rhel63-4.5/ws/dist/rpmbuild/BUILDROOT/cloudstack-4.5.1-SNAPSHOT.el6.x86_64 + cd cloudstack-4.5.1-SNAPSHOT + LANG=C + export LANG + unset DISPLAY + '[' http://jenkins.buildacloud.org/job/package-rhel63-4.5/ws/dist/rpmbuild/BUILDROOT/cloudstack-4.5.1-SNAPSHOT.el6.x86_64 '!=' / ']' + rm -rf http://jenkins.buildacloud.org/job/package-rhel63-4.5/ws/dist/rpmbuild/BUILDROOT/cloudstack-4.5.1-SNAPSHOT.el6.x86_64 + mkdir -p http://jenkins.buildacloud.org/job/package-rhel63-4.5/ws/dist/rpmbuild/BUILDROOT/cloudstack-4.5.1-SNAPSHOT.el6.x86_64/usr/bin + mkdir -p http://jenkins.buildacloud.org/job/package-rhel63-4.5/ws/dist/rpmbuild/BUILDROOT/cloudstack-4.5.1-SNAPSHOT.el6.x86_64/var/log/cloudstack/agent + mkdir -p http://jenkins.buildacloud.org/job/package-rhel63-4.5/ws/dist/rpmbuild/BUILDROOT/cloudstack-4.5.1-SNAPSHOT.el6.x86_64/var/log/cloudstack/awsapi + mkdir -p http://jenkins.buildacloud.org/job/package-rhel63-4.5/ws/dist/rpmbuild/BUILDROOT/cloudstack-4.5.1-SNAPSHOT.el6.x86_64/var/log/cloudstack/ipallocator + mkdir -p http://jenkins.buildacloud.org/job/package-rhel63-4.5/ws/dist/rpmbuild/BUILDROOT/cloudstack-4.5.1-SNAPSHOT.el6.x86_64/var/cache/cloudstack/management/work + mkdir -p
Re: Require write/edit access to Cloudstack wiki
Thanks Rajani. Regards, Gaurav On Thu, Mar 19, 2015 at 10:05 AM, Rajani Karuturi raj...@apache.org wrote: done ~Rajani On Thu, Mar 19, 2015 at 9:53 AM, Gaurav Aradhye gaurav.arad...@clogeny.com wrote: I would like to add a page to wiki stating Guidelines for test developers. Can somebody give me access? My username is aradhye.gaurav Regards, Gaurav
Re: Review Request 27611: CLOUDSTACK-6282 - Added automated tests for filter feature
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27611/ --- (Updated March 19, 2015, 5:08 a.m.) Review request for cloudstack and Santhosh Edukulla. Changes --- Modified the tests and incorporated the review comments. Bugs: CLOUDSTACK-6282 https://issues.apache.org/jira/browse/CLOUDSTACK-6282 Repository: cloudstack-git Description --- CLOUDSTACK-6282 - Added automated tests for filter feature Diffs (updated) - test/integration/component/test_escalations_ipaddresses.py c60c5b6 test/integration/component/test_escalations_isos.py 4e818a5 test/integration/component/test_escalations_networks.py fb2196c test/integration/component/test_escalations_volumes.py 58f5845 test/integration/component/test_escalations_vpncustomergateways.py b09930a Diff: https://reviews.apache.org/r/27611/diff/ Testing --- Tested all the files to which tests are added and atatched are the result files File Attachments IPAddressresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/3b21a80f-2917-4650-a9ca-3e213afb26fc__IPAddressresults.txt ISOresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/2cd44d83-e7e5-47be-9c80-03d9a2f4f710__ISOresults.txt Networksresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/7661c962-f561-4e83-8b37-bc6676bc6808__Networksresults.txt SecurityGroupsresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/2a2d8465-2f58-4049-ad93-f878c33d5faa__SecurityGroupsresults.txt Snapshotresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/63ba74be-bc72-4419-8b7b-1fa788275be2__Snapshotresults.txt Templatesresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/c51e1861-7137-4186-82c8-7e3c85a31905__Templatesresults.txt Volumeresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/f1a11419-aa10-48e0-8291-ceb762d4a734__Volumeresults.txt VPNCustomerGatewaysresults.txt https://reviews.apache.org/media/uploaded/files/2014/11/05/4c8d2447-016e-49c0-9db2-b255625cd33f__VPNCustomerGatewaysresults.txt Thanks, Avinash Gautam
Build failed in Jenkins: build-4.5-simulator #225
See http://jenkins.buildacloud.org/job/build-4.5-simulator/225/ -- Started by upstream project build-4.5 build number 406 originally caused by: Started by user Pierre-Luc Dion [EnvInject] - Loading node environment variables. Building remotely on coohq-slave-01 (cloudstack-buildslave-centos6 systemvmbuilder) in workspace http://jenkins.buildacloud.org/job/build-4.5-simulator/ws/ Cloning the remote Git repository Cloning repository https://git-wip-us.apache.org/repos/asf/cloudstack.git /usr/bin/git init http://jenkins.buildacloud.org/job/build-4.5-simulator/ws/ # timeout=10 Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/cloudstack.git /usr/bin/git --version # timeout=10 /usr/bin/git -c core.askpass=true fetch --tags --progress https://git-wip-us.apache.org/repos/asf/cloudstack.git +refs/heads/*:refs/remotes/origin/* ERROR: Timeout after 10 minutes ERROR: Error cloning remote repo 'origin' ERROR: Error cloning remote repo 'origin' Recording test results ERROR: Publisher hudson.tasks.junit.JUnitResultArchiver aborted due to exception hudson.AbortException: No test report files were found. Configuration error? at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:116) at hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:93) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2665) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:324) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ..remote call to coohq-slave-01(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:752) at hudson.FilePath.act(FilePath.java:970) at hudson.FilePath.act(FilePath.java:959) at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:90) at hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:120) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:137) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683) at hudson.model.Run.execute(Run.java:1784) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240)
Re: Require write/edit access to Cloudstack wiki
done ~Rajani On Thu, Mar 19, 2015 at 9:53 AM, Gaurav Aradhye gaurav.arad...@clogeny.com wrote: I would like to add a page to wiki stating Guidelines for test developers. Can somebody give me access? My username is aradhye.gaurav Regards, Gaurav
Jenkins build is back to normal : build-master-noredist #4150
See http://jenkins.buildacloud.org/job/build-master-noredist/4150/changes
Re: junkins
Thanks Pierre-Luc ~Rajani On Thu, Mar 19, 2015 at 8:50 AM, Pierre-Luc Dion pd...@cloudops.com wrote: I've fixed the slave msaz-slave-01 so it can build centos7 rpms and add the label cloudstack-buildslave-centos6 to coohq-slave-01. coohq-slave-01 run Ubuntu 14.04 I hope it does not affect something. some build jobs are back to green. On Wed, Mar 18, 2015 at 11:53 AM, Ian Southam isout...@schubergphilis.com wrote: Daan, On 17 Mar 2015, at 12:23, Daan Hoogland daan.hoogl...@gmail.commailto: daan.hoogl...@gmail.com wrote: Laszlo, I don't think anyone is working on this. Jenkins output is largely ignored in this community. The fact that the present cause is a resource problem is worrying. I think these are SBP hosted slaves and will have a look (not in the office now). If I fix this the slowbuild will not work at least. The last time I saw it passing by it had 6 new unattended issues from the findbugs output. Coverity complained about new issues as well, i noticed just now. Do I have access to these boxes? Quite happy to have a look. — Ian
Build failed in Jenkins: simulator-4.5-singlerun #180
See http://jenkins.buildacloud.org/job/simulator-4.5-singlerun/180/changes Changes: [Rohit Yadav] CLOUDSTACK-7639: make cidrlist update when updateNetworkAclItem is called [Rohit Yadav] CLOUDSTACK-7639: make cidr updation more efficient [Rohit Yadav] systemvm: avoid tcp responses with timestamp [Rohit Yadav] systemvm: correct sftp subsystem path of debian wheezy [Rohit Yadav] scripts: add ip set interface up because in CentOS7 the interface will not auto up [Rohit Yadav] CLOUDSTACK-8312: The storage usage of Primary Storage Allocated is incorrect. [Rohit Yadav] CLOUDSTACK-8304: disable snapshots from non-snapshot repositories [Rohit Yadav] systemvms: use Debian http redirector for apt repos [Rohit Yadav] api: avoid sending sensitive data in api response [Rohit Yadav] CLOUDSTACK-8315: CS API listVMSnapshot doesn't have tags ‘project’ and ‘projectid’. [Rohit Yadav] server: remove unused import in ImageStoreJoinDaoImpl [Rohit Yadav] Update pom and version usage to 4.5.1-SNAPSHOT [Rohit Yadav] engine: Add Upgrade path from 4.5.0 to 4.5.1 [Rohit Yadav] CLOUDSTACK-8272: Python based file-lock free password server implementation [Rohit Yadav] Fix encoding for user account label in header [Rohit Yadav] Error message exposes domain Id when deployVirtualMachine() is attempted on a shared network to which the user doesnot have access to. [Rohit Yadav] CS-20680: The user's secret key is not encrypted in the UserCredentialsVO class [Rohit Yadav] CS-19734:Session cookie is exposed to scripts. [Rohit Yadav] CS-18149: UI - no longer store sessionKey in cookie. After [Rohit Yadav] CS-17504: Weak SSL ciphers supported by the management server [Rohit Yadav] Avoid distributing private key for realhostip.com [Rohit Yadav] Avoid logging password when adding srx device [Rohit Yadav] ui: if session cookie exists, use it to set global session holder and invalidate it [Rohit Yadav] utils: use a better extended implementation of SSLSocketFactory [Rajani Karuturi] CLOUDSTACK-7348 InvalidParameter Exception while executing scale vm. [Rajani Karuturi] CLOUDSTACK-5236 : ability to identify where the user is from (ex. LDAP) [Rohit Yadav] user-authenticators: don't allow empty usernames or passwords [w.zhou] UI: Fix typo in ui/scripts/configuration.js [w.zhou] CLOUDSTACK-8329: CloudStack accepts IP ends with dot [Rajani Karuturi] Fixed build failure due to commit 843f6b16914159ea6241c6c1a0a04e9d0fefaed4 [Rohit Yadav] savepassword: use eth0's IP address, as password listens on that IP [Rohit Yadav] CLOUDSTACK-8331: savepassword should try all IPs on eth0 [Rohit Yadav] vpc_passwd_server: use the improved Python based password server [Rohit Yadav] CLOUDSTACK-8331: have savepassword try all interfaces -- [...truncated 8858 lines...] Processing SQL file at http://jenkins.buildacloud.org/job/simulator-4.5-singlerun/ws/developer/target/db/cloudbridge_index.sql Processing SQL file at http://jenkins.buildacloud.org/job/simulator-4.5-singlerun/ws/developer/target/db/cloudbridge_multipart_alter.sql Processing SQL file at http://jenkins.buildacloud.org/job/simulator-4.5-singlerun/ws/developer/target/db/cloudbridge_bucketpolicy.sql Processing SQL file at http://jenkins.buildacloud.org/job/simulator-4.5-singlerun/ws/developer/target/db/cloudbridge_policy_alter.sql Processing SQL file at http://jenkins.buildacloud.org/job/simulator-4.5-singlerun/ws/developer/target/db/cloudbridge_offering.sql Processing SQL file at http://jenkins.buildacloud.org/job/simulator-4.5-singlerun/ws/developer/target/db/cloudbridge_offering_alter.sql Processing SQL file at http://jenkins.buildacloud.org/job/simulator-4.5-singlerun/ws/developer/developer-prefill.sql Processing upgrade: com.cloud.upgrade.DatabaseUpgradeChecker [INFO] [INFO] --- maven-site-plugin:3.3:attach-descriptor (attach-descriptor) @ cloud-developer --- [INFO] [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ cloud-developer --- [INFO] Installing http://jenkins.buildacloud.org/job/simulator-4.5-singlerun/ws/developer/pom.xml to /var/lib/jenkins/.m2/repository/org/apache/cloudstack/cloud-developer/4.5.1-SNAPSHOT/cloud-developer-4.5.1-SNAPSHOT.pom [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 2:03.730s [INFO] Finished at: Wed Mar 18 23:56:13 EDT 2015 [INFO] Final Memory: 42M/190M [INFO] [WARNING] The requested profile simulator could not be activated because it does not exist. [simulator-4.5-singlerun] $ mvn -P developer -pl developer -Ddeploydb-simulator [INFO] Scanning for projects... [INFO] [INFO]
Re: Guidelines for test developers
I have added Wiki page for this in QA section. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Guidelines+for+test+developers Not a very polished one, but I will be adding and polishing it soon. Regards, Gaurav On Thu, Mar 19, 2015 at 9:52 AM, Gaurav Aradhye gaurav.arad...@clogeny.com wrote: Paul, Some pages on wiki talk about general guidelines to Dev, but there is no page stating detailed guidelines for test developers. I would like to add a new page in QA section for this. Will drop separate mail for write access to wiki. Daan, I will have to check on this. I will find out how we can include static analysis for tests similar to that it is in place for dev code (findbugs). Regards, Gaurav On Wed, Mar 18, 2015 at 8:22 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: good write-up Gaurav, I hope that most of these can be validated/verified checkstyle-style. pep8 can of course. Some others must remain judged by humanoids, like the one where functions are pulled up to higher abstraction layers. Maybe you could shine your light on what we can automate? i.e. can pyflakes be added to a target? -Original Message- From: Gaurav Aradhye [mailto:gaurav.arad...@clogeny.com] Sent: 18 March 2015 07:16 To: dev@cloudstack.apache.org Subject: Guidelines for test developers Hello all, Last year after improving Marvin framework, we have been continuously spending time in improving old test cases which are written in old style or they don't abide to certain guidelines, also which don't use new functions available in marvin. Many times a test developer who is adding test case for the first time or feature developers adding Basic Validation Tests (BVTs) tend to copy paste the code available in certain test case and try to modify it according to feature and commit it. This adds to inconsistencies. As and when I touch a file for fixing an issue or adding/editing it, I try to incorporate below guidelines and improve the existing code. But still few test files are not up to the mark. Our final goal is to have good code in every file.So writing this mail to consolidate few rules that should be known/considered by everyone adding tests to Marvin. Also, if you touch a file, feel free to remove any inconsistencies that are already present in the file. *1. Import * should always be avoided*. When I started two years back, and tried to understand the code flow/ test cases, I could not easily understand from where the particular module is imported. The imports must be specific. When the imports are specific, it eliminates the possibility of test case failure due to invalid import when specific import is removed from dependent module. E.g. If your test case has following import. from A import * And it uses time module which is not imported explicitly in test case and comes from module A. Then the test case will start failing when import timeis removed from module A. You certainly don't want this to happen. *2. Maintaining Pep8 standards for python code.* The code is read more often that it is written. Pep8 standards improve the readability of the code making it consistent in style. There is a tool named *autopep8* which you can install with pip install and then you can run following command on your test file. autopep8 -i -a -a testFile.py This will make the file pep8 consistent and will also remove the white spaces. But some issues need human intervention and can't be fixed with tool. For fixing those, check the pep8 issues with pep8 testFile.py and fix manually. *3. Keep only imports which are used* in the test suite and remove unwanted imports. *4. Keep all the configuration parameters* (such as data which is passed to API while creating Network offering, Service offering, account etc...) *in tools/marvin/marvin/config/test_data.py file*. Don't include them in test suite itself. Many of the dictionaries are reusable and if you are adding a new test, there are only a few dictionaries you will have to add in the file. If any of the data contains URLs or any data which should be changed according to setup/env, then include the dict in *configurableData* section in test_data.py file. This makes it easier to identify which data needs to be dynamic according to the setup and which data doesn't need to be touched when env is changed. *5. Before committing a test case, run it* with the latest branch against which you are adding the test case and attach the results in Pull Request. If in case change is very small, and doesn't need to be run, then at least check syntactical errors with python command and also with the help of tools such as pyflakes. 6. If you add a new function in your test case and you think it can be used in future by other test cases, then please *add that function to common or utils file* in Marvin. Don't keep it local to test case. This will prevent
Re: Root disk size support in UI - problem with instanceWizard.js
If it's to save on download sizes, I prefer John's approach to proxy and cache via Apache HTTPd (which brings other advantages as well, like easy SSL configuration, mod_security etc etc). http://theresnomon.co/2014/improving-cloudstack-ui-performance/ Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Nux! n...@li.nux.ro To: dev@cloudstack.apache.org Sent: Wednesday, 18 March, 2015 19:34:02 Subject: Re: Root disk size support in UI - problem with instanceWizard.js Marcus, Thanks, after gzipping it I can see the field! Why are we doing this? -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Marcus shadow...@gmail.com To: dev@cloudstack.apache.org Sent: Wednesday, 18 March, 2015 18:55:08 Subject: Re: Root disk size support in UI - problem with instanceWizard.js for 4.5, you'll need to gzip any js files after editing them. At least that's what I've observed. You should see a .js and a .js.gz for each. On Wed, Mar 18, 2015 at 11:44 AM, Nux! n...@li.nux.ro wrote: Thanks Ian, tried your suggestions, but to no effect that I can observe. The root disk field does not appear on the instance creation page. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Ian Duffy i...@ianduffy.ie To: CloudStack Dev dev@cloudstack.apache.org Sent: Wednesday, 18 March, 2015 16:52:30 Subject: Re: Root disk size support in UI - problem with instanceWizard.js Hey Nux, This is completely untested and based of reading the source code. Within ui/scripts/ui-custom/instanceWizard.js on line ~ 424 you should find a call to the custom hidden function which determines whether or not to set display = none on the root resize box. Within the ui/scripts/instanceWizard.js you'll see that the root resize is applied if its element isn't set to display none. I'd suggest just setting var custom = false; as a quick and easy fix. https://github.com/apache/cloudstack/blob/master/ui/scripts/ui-custom/instanceWizard.js#L424-437 On 18 March 2015 at 16:25, Nux! n...@li.nux.ro wrote: Hello, In my 4.4.1 install I can use this patch[1] to specify a custom root disk size for an instance[2]. This is of course very handy, enabled me to get rid of tens of templates with custom sizes. In 4.5 this patch no longer does it's job, there is no Root Disk field appearing during instance creation. Can anyone have a look? [1] https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=ui/scripts/instanceWizard.js;h=4a740c6685e05449290f1fe378add9a6c71f96ad;hp=646ffbf5b1922fc618bb3ad0091fe15895c24226;hb=8fec09ba481fbd3b8c2a9e4d31ef06f113b037cb;hpb=c1af92fcbbc183873d6519f0660b68acfb33bd44 [2] http://img.nux.ro/Fw3-Selection_020.png - This is a KVM only feature for now -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Re: Root disk size support in UI - problem with instanceWizard.js
Thanks Ian, tried your suggestions, but to no effect that I can observe. The root disk field does not appear on the instance creation page. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Ian Duffy i...@ianduffy.ie To: CloudStack Dev dev@cloudstack.apache.org Sent: Wednesday, 18 March, 2015 16:52:30 Subject: Re: Root disk size support in UI - problem with instanceWizard.js Hey Nux, This is completely untested and based of reading the source code. Within ui/scripts/ui-custom/instanceWizard.js on line ~ 424 you should find a call to the custom hidden function which determines whether or not to set display = none on the root resize box. Within the ui/scripts/instanceWizard.js you'll see that the root resize is applied if its element isn't set to display none. I'd suggest just setting var custom = false; as a quick and easy fix. https://github.com/apache/cloudstack/blob/master/ui/scripts/ui-custom/instanceWizard.js#L424-437 On 18 March 2015 at 16:25, Nux! n...@li.nux.ro wrote: Hello, In my 4.4.1 install I can use this patch[1] to specify a custom root disk size for an instance[2]. This is of course very handy, enabled me to get rid of tens of templates with custom sizes. In 4.5 this patch no longer does it's job, there is no Root Disk field appearing during instance creation. Can anyone have a look? [1] https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=ui/scripts/instanceWizard.js;h=4a740c6685e05449290f1fe378add9a6c71f96ad;hp=646ffbf5b1922fc618bb3ad0091fe15895c24226;hb=8fec09ba481fbd3b8c2a9e4d31ef06f113b037cb;hpb=c1af92fcbbc183873d6519f0660b68acfb33bd44 [2] http://img.nux.ro/Fw3-Selection_020.png - This is a KVM only feature for now -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Re: Root disk size support in UI - problem with instanceWizard.js
Marcus, Thanks, after gzipping it I can see the field! Why are we doing this? -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Marcus shadow...@gmail.com To: dev@cloudstack.apache.org Sent: Wednesday, 18 March, 2015 18:55:08 Subject: Re: Root disk size support in UI - problem with instanceWizard.js for 4.5, you'll need to gzip any js files after editing them. At least that's what I've observed. You should see a .js and a .js.gz for each. On Wed, Mar 18, 2015 at 11:44 AM, Nux! n...@li.nux.ro wrote: Thanks Ian, tried your suggestions, but to no effect that I can observe. The root disk field does not appear on the instance creation page. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Ian Duffy i...@ianduffy.ie To: CloudStack Dev dev@cloudstack.apache.org Sent: Wednesday, 18 March, 2015 16:52:30 Subject: Re: Root disk size support in UI - problem with instanceWizard.js Hey Nux, This is completely untested and based of reading the source code. Within ui/scripts/ui-custom/instanceWizard.js on line ~ 424 you should find a call to the custom hidden function which determines whether or not to set display = none on the root resize box. Within the ui/scripts/instanceWizard.js you'll see that the root resize is applied if its element isn't set to display none. I'd suggest just setting var custom = false; as a quick and easy fix. https://github.com/apache/cloudstack/blob/master/ui/scripts/ui-custom/instanceWizard.js#L424-437 On 18 March 2015 at 16:25, Nux! n...@li.nux.ro wrote: Hello, In my 4.4.1 install I can use this patch[1] to specify a custom root disk size for an instance[2]. This is of course very handy, enabled me to get rid of tens of templates with custom sizes. In 4.5 this patch no longer does it's job, there is no Root Disk field appearing during instance creation. Can anyone have a look? [1] https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=ui/scripts/instanceWizard.js;h=4a740c6685e05449290f1fe378add9a6c71f96ad;hp=646ffbf5b1922fc618bb3ad0091fe15895c24226;hb=8fec09ba481fbd3b8c2a9e4d31ef06f113b037cb;hpb=c1af92fcbbc183873d6519f0660b68acfb33bd44 [2] http://img.nux.ro/Fw3-Selection_020.png - This is a KVM only feature for now -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
Re: Cloudstack modules on maven repository
Hey, There is an apache Nexus repository available at https://repository.apache.org If you search cloudstack you will see there are some old builds up there https://repository.apache.org/#nexus-search;quick~cloudstack There is documentation on the apache site about pushing items up there http://www.apache.org/dev/publishing-maven-artifacts.html It would be neat if we could get our CI to do versioning and push a build artifact for each build. ** slightly off topic ** Awhile back I changed some of the jenkins jobs to expose the cloud-client-ui war. All of the JARs are included within this. This script (https://github.com/imduffy15/cloudstack-cloudmonkey/blob/master/.tools/ci/cloudstack-simulator.sh) shows downloading that war, unzipping it, finding the database util classes, running the database creator scripts and deploying the WAR with jetty. http://jenkins.buildacloud.org/view/4.3/job/cloudstack-4.3-maven-build-noredist/lastSuccessfulBuild/ On 18 March 2015 at 21:15, Rafael Weingartner rafaelweingart...@gmail.com wrote: Got it. Thanks for registering the jira issue. I was going to do that. ;) On Wed, Mar 18, 2015 at 6:00 PM, Laszlo Hornyak laszlo.horn...@gmail.com wrote: Hi, As far asI know, there is no such repsoitory. It would be great to use the central repository, but first we have to get rid of extra maven repositories. (libvirt and ceph for example) I registered a jira issue: https://issues.apache.org/jira/browse/CLOUDSTACK-8335 On Wed, Mar 18, 2015 at 9:15 PM, Rafael Weingartner rafaelweingart...@gmail.com wrote: Hi devs, I just started extending Cloustack, I have spent almost a whole day configuring and building everything on eclipse. I noticed that CS modules are not in maven central repository, therefore, I have to download, configure, compile and build everything in order to work in one or other module. I was wondering is there any repository out there on the Internet, maybe an apache dev repository, with all of those modules ready to use that I can point as an extra repository in maven? -- Rafael Weingärtner -- EOF -- Rafael Weingärtner
Re: BUG: anybody addressing this one ?
It looks like we have 2 issues here. 1) you are seeing volumes you should not see 2) volume purging is not implemented There are several solution to #2 1) I've written a shell script that deletes all volumes that are in detached state for over X number of days. I'll see if i can share the script. This could be temporary solution run as cronjob periodically. 2) Marcus has written an API extension call that will delete the VM with volumes, slightly different API call needs to be invoked, something like destroyVmWithVolumes, the volumes will be expunged at the same time as VM. Its not part of the cloudstack UI, but could be integrated - hoping someone with UI experience can do that. The code will be committed upstream hopefully soon, there is some internal delay for releasing that, but we will work this through. On 3/18/15 4:58 AM, Andrija Panic wrote: Hi, https://issues.apache.org/jira/browse/CLOUDSTACK-7926 Currently I have hit a bug, when I click on some instance, then on View Volumes, and then I get listed volumes that belong to some other VM - it already happened to me that I deleted the volumes - beacuse of ACS bug in GUI ! So, I suggest to consider maybe to implement purging volumes the same way it is implemented with VM-s - so the VM is not really deleted - and the purge thread in ACS will acually delete it when it runs...
Build failed in Jenkins: cloudstack-4.4-maven-build #594
See http://jenkins.buildacloud.org/job/cloudstack-4.4-maven-build/594/changes Changes: [Daan Hoogland] Avoid distributing private key for realhostip.com -- [...truncated 9576 lines...] 359/612 KB 344/380 KB 363/612 KB 344/380 KB 367/612 KB 344/380 KB 371/612 KB 344/380 KB 375/612 KB 344/380 KB 379/612 KB 344/380 KB 383/612 KB 344/380 KB 387/612 KB 344/380 KB 391/612 KB 344/380 KB 395/612 KB 344/380 KB 395/612 KB 348/380 KB 395/612 KB 349/380 KB 395/612 KB 352/380 KB 395/612 KB 355/380 KB 395/612 KB 359/380 KB 395/612 KB 363/380 KB 395/612 KB 367/380 KB 395/612 KB 371/380 KB 395/612 KB 375/380 KB 395/612 KB 379/380 KB 395/612 KB 380/380 KB 399/612 KB 380/380 KB 403/612 KB 380/380 KB 407/612 KB 380/380 KB 411/612 KB 380/380 KB 415/612 KB 380/380 KB 419/612 KB 380/380 KB 423/612 KB 380/380 KB 427/612 KB 380/380 KB 431/612 KB 380/380 KB 435/612 KB 380/380 KB 439/612 KB 380/380 KB 443/612 KB 380/380 KB 447/612 KB 380/380 KB 451/612 KB 380/380 KB 455/612 KB 380/380 KB 459/612 KB 380/380 KB 463/612 KB 380/380 KB 467/612 KB 380/380 KB 471/612 KB 380/380 KB 475/612 KB 380/380 KB 479/612 KB 380/380 KB 483/612 KB 380/380 KB 487/612 KB 380/380 KB 491/612 KB 380/380 KB 495/612 KB 380/380 KB 499/612 KB 380/380 KB 503/612 KB 380/380 KB 507/612 KB 380/380 KB 511/612 KB 380/380 KB 515/612 KB 380/380 KB 519/612 KB 380/380 KB 523/612 KB 380/380 KB 527/612 KB 380/380 KB 531/612 KB 380/380 KB 535/612 KB 380/380 KB 539/612 KB 380/380 KB 543/612 KB 380/380 KB 544/612 KB 380/380 KB 548/612 KB 380/380 KB 552/612 KB 380/380 KB 556/612 KB 380/380 KB 560/612 KB 380/380 KB 564/612 KB 380/380 KB 568/612 KB 380/380 KB 572/612 KB 380/380 KB 576/612 KB 380/380 KB 580/612 KB 380/380 KB 584/612 KB 380/380 KB 588/612 KB 380/380 KB 592/612 KB 380/380 KB 596/612 KB 380/380 KB 600/612 KB 380/380 KB 604/612 KB 380/380 KB 608/612 KB 380/380 KB 612/612 KB 380/380 KB Downloaded: http://repo.maven.apache.org/maven2/javax/mail/mail/1.4/mail-1.4.jar (380 KB at 2133.4 KB/sec) Downloaded: http://repo.maven.apache.org/maven2/org/springframework/spring-web/3.2.4.RELEASE/spring-web-3.2.4.RELEASE.jar (612 KB at 3086.9 KB/sec) [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cloud-server --- [INFO] Deleting http://jenkins.buildacloud.org/job/cloudstack-4.4-maven-build/ws/server (includes = [target, dist], excludes = []) [INFO] [INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ cloud-server --- [INFO] Starting audit... Audit done. [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.4-maven-build/ws/server/target/conf [copy] Copying 1 file to http://jenkins.buildacloud.org/job/cloudstack-4.4-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 360 source files to http://jenkins.buildacloud.org/job/cloudstack-4.4-maven-build/ws/server/target/classes [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] http://jenkins.buildacloud.org/job/cloudstack-4.4-maven-build/ws/server/src/com/cloud/consoleproxy/AgentHookBase.java:[195,12] error: cannot find symbol [ERROR] symbol: class SecureRandom location: class AgentHookBase http://jenkins.buildacloud.org/job/cloudstack-4.4-maven-build/ws/server/src/com/cloud/consoleproxy/AgentHookBase.java:[195,34] error: cannot find symbol [ERROR] symbol: variable SecureRandom location: class AgentHookBase http://jenkins.buildacloud.org/job/cloudstack-4.4-maven-build/ws/server/src/com/cloud/consoleproxy/AgentHookBase.java:[199,19] error: variable storePassword is already defined in method startAgentHttpHandlerInVM(StartupProxyCommand) [ERROR] http://jenkins.buildacloud.org/job/cloudstack-4.4-maven-build/ws/server/src/com/cloud/consoleproxy/AgentHookBase.java:[199,35] error: cannot find symbol [ERROR] symbol: variable Base64 location: class AgentHookBase
Cloudstack modules on maven repository
Hi devs, I just started extending Cloustack, I have spent almost a whole day configuring and building everything on eclipse. I noticed that CS modules are not in maven central repository, therefore, I have to download, configure, compile and build everything in order to work in one or other module. I was wondering is there any repository out there on the Internet, maybe an apache dev repository, with all of those modules ready to use that I can point as an extra repository in maven? -- Rafael Weingärtner
Re: Cloudstack modules on maven repository
Hi, As far asI know, there is no such repsoitory. It would be great to use the central repository, but first we have to get rid of extra maven repositories. (libvirt and ceph for example) I registered a jira issue: https://issues.apache.org/jira/browse/CLOUDSTACK-8335 On Wed, Mar 18, 2015 at 9:15 PM, Rafael Weingartner rafaelweingart...@gmail.com wrote: Hi devs, I just started extending Cloustack, I have spent almost a whole day configuring and building everything on eclipse. I noticed that CS modules are not in maven central repository, therefore, I have to download, configure, compile and build everything in order to work in one or other module. I was wondering is there any repository out there on the Internet, maybe an apache dev repository, with all of those modules ready to use that I can point as an extra repository in maven? -- Rafael Weingärtner -- EOF
Re: Cloudstack modules on maven repository
Got it. Thanks for registering the jira issue. I was going to do that. ;) On Wed, Mar 18, 2015 at 6:00 PM, Laszlo Hornyak laszlo.horn...@gmail.com wrote: Hi, As far asI know, there is no such repsoitory. It would be great to use the central repository, but first we have to get rid of extra maven repositories. (libvirt and ceph for example) I registered a jira issue: https://issues.apache.org/jira/browse/CLOUDSTACK-8335 On Wed, Mar 18, 2015 at 9:15 PM, Rafael Weingartner rafaelweingart...@gmail.com wrote: Hi devs, I just started extending Cloustack, I have spent almost a whole day configuring and building everything on eclipse. I noticed that CS modules are not in maven central repository, therefore, I have to download, configure, compile and build everything in order to work in one or other module. I was wondering is there any repository out there on the Internet, maybe an apache dev repository, with all of those modules ready to use that I can point as an extra repository in maven? -- Rafael Weingärtner -- EOF -- Rafael Weingärtner
Re: BUG: anybody addressing this one ?
Well, I think many people will want to be able to leave disks detached without deleting them, I'm not sure what the use case was that caused Andrija to want to delete those disks. It sounds like he wanted to delete attached disks and keep the vm. From experience, it would be relatively trivial to have a 'deleteVolume deferred=true' parameter that simply marks the volume as destroyed, then the storage cleanup thread will expunge it. The list volumes api call would also need to be changed to show destroyed volumes optionally, and there'd need to be a new API call that allows you to mark the volume read again to 'undo'. This isn't much work but unfortunately I'm not in a position to do that at the moment. The big issue is really that drilling down into members of entities in the UI seems to be broken, whether it's view volumes attached to a vm or view instances on a host. On Wed, Mar 18, 2015 at 12:52 PM, ilya ilya.mailing.li...@gmail.com wrote: It looks like we have 2 issues here. 1) you are seeing volumes you should not see 2) volume purging is not implemented There are several solution to #2 1) I've written a shell script that deletes all volumes that are in detached state for over X number of days. I'll see if i can share the script. This could be temporary solution run as cronjob periodically. 2) Marcus has written an API extension call that will delete the VM with volumes, slightly different API call needs to be invoked, something like destroyVmWithVolumes, the volumes will be expunged at the same time as VM. Its not part of the cloudstack UI, but could be integrated - hoping someone with UI experience can do that. The code will be committed upstream hopefully soon, there is some internal delay for releasing that, but we will work this through. On 3/18/15 4:58 AM, Andrija Panic wrote: Hi, https://issues.apache.org/jira/browse/CLOUDSTACK-7926 Currently I have hit a bug, when I click on some instance, then on View Volumes, and then I get listed volumes that belong to some other VM - it already happened to me that I deleted the volumes - beacuse of ACS bug in GUI ! So, I suggest to consider maybe to implement purging volumes the same way it is implemented with VM-s - so the VM is not really deleted - and the purge thread in ACS will acually delete it when it runs...
Re: Root disk size support in UI - problem with instanceWizard.js
I don't recall. There was a big long thread about it at one point, but I wasn't paying full attention to it. On Wed, Mar 18, 2015 at 12:39 PM, Nux! n...@li.nux.ro wrote: If it's to save on download sizes, I prefer John's approach to proxy and cache via Apache HTTPd (which brings other advantages as well, like easy SSL configuration, mod_security etc etc). http://theresnomon.co/2014/improving-cloudstack-ui-performance/ Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Nux! n...@li.nux.ro To: dev@cloudstack.apache.org Sent: Wednesday, 18 March, 2015 19:34:02 Subject: Re: Root disk size support in UI - problem with instanceWizard.js Marcus, Thanks, after gzipping it I can see the field! Why are we doing this? -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Marcus shadow...@gmail.com To: dev@cloudstack.apache.org Sent: Wednesday, 18 March, 2015 18:55:08 Subject: Re: Root disk size support in UI - problem with instanceWizard.js for 4.5, you'll need to gzip any js files after editing them. At least that's what I've observed. You should see a .js and a .js.gz for each. On Wed, Mar 18, 2015 at 11:44 AM, Nux! n...@li.nux.ro wrote: Thanks Ian, tried your suggestions, but to no effect that I can observe. The root disk field does not appear on the instance creation page. Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Ian Duffy i...@ianduffy.ie To: CloudStack Dev dev@cloudstack.apache.org Sent: Wednesday, 18 March, 2015 16:52:30 Subject: Re: Root disk size support in UI - problem with instanceWizard.js Hey Nux, This is completely untested and based of reading the source code. Within ui/scripts/ui-custom/instanceWizard.js on line ~ 424 you should find a call to the custom hidden function which determines whether or not to set display = none on the root resize box. Within the ui/scripts/instanceWizard.js you'll see that the root resize is applied if its element isn't set to display none. I'd suggest just setting var custom = false; as a quick and easy fix. https://github.com/apache/cloudstack/blob/master/ui/scripts/ui-custom/instanceWizard.js#L424-437 On 18 March 2015 at 16:25, Nux! n...@li.nux.ro wrote: Hello, In my 4.4.1 install I can use this patch[1] to specify a custom root disk size for an instance[2]. This is of course very handy, enabled me to get rid of tens of templates with custom sizes. In 4.5 this patch no longer does it's job, there is no Root Disk field appearing during instance creation. Can anyone have a look? [1] https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blobdiff;f=ui/scripts/instanceWizard.js;h=4a740c6685e05449290f1fe378add9a6c71f96ad;hp=646ffbf5b1922fc618bb3ad0091fe15895c24226;hb=8fec09ba481fbd3b8c2a9e4d31ef06f113b037cb;hpb=c1af92fcbbc183873d6519f0660b68acfb33bd44 [2] http://img.nux.ro/Fw3-Selection_020.png - This is a KVM only feature for now -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro
