Re: Review Request 28049: CLOUDSTACK-7917: Load Balancer Rule is not validated when updating LB
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28049/#review62950 --- Ship it! Ship It! - Rajani Karuturi On Nov. 24, 2014, 4:23 p.m., Daniel Vega Simoes wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28049/ --- (Updated Nov. 24, 2014, 4:23 p.m.) Review request for cloudstack. Repository: cloudstack-git Description --- JIRA: https://issues.apache.org/jira/browse/CLOUDSTACK-7917 Validate Load Balancer rule with provider before commiting to DB and applying new rule. Diffs - server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java a28d108 server/test/com/cloud/network/lb/UpdateLoadBalancerTest.java PRE-CREATION Diff: https://reviews.apache.org/r/28049/diff/ Testing --- Created 2 new unit tests that are located in server/test/com/cloud/network/lb/UpdateLoadBalancerTest.java - Test to guarantee that validate is being called when updating LB rule - Test to guarantee that it throws exception if LB rule is not validated by provider Ran integration tests (smoke), all seems OK. Thanks, Daniel Vega Simoes
Re: Review Request 28043: CLOUDSTACK 7915: Remove hard-coded values for Load Balancer algorithms in UI
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28043/#review62953 --- Ship it! Ship It! - Rajani Karuturi On Nov. 17, 2014, 6:26 p.m., Daniel Vega Simoes wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28043/ --- (Updated Nov. 17, 2014, 6:26 p.m.) Review request for cloudstack. Repository: cloudstack-git Description --- JIRA: CLOUDSTACK 7915 Removed hard-coded values for Load Balancer algorithms in UI. Instead, now UI sets values loaded dynamically through load balancer provider capabilities. Also updated internationalization messages. Diffs - client/WEB-INF/classes/resources/messages.properties 86eb5c2 client/WEB-INF/classes/resources/messages_ar.properties 4f65118 client/WEB-INF/classes/resources/messages_es.properties f2d754e client/WEB-INF/classes/resources/messages_fr_FR.properties 004187f client/WEB-INF/classes/resources/messages_it_IT.properties e2f3f0b client/WEB-INF/classes/resources/messages_ja_JP.properties 7bc90b5 client/WEB-INF/classes/resources/messages_ko_KR.properties ce79d2e client/WEB-INF/classes/resources/messages_nb_NO.properties c169112 client/WEB-INF/classes/resources/messages_nl_NL.properties 89ef828 client/WEB-INF/classes/resources/messages_pl.properties 06d5ec2 client/WEB-INF/classes/resources/messages_pt_BR.properties 8ee08ba client/WEB-INF/classes/resources/messages_ru_RU.properties ff68668 client/WEB-INF/classes/resources/messages_zh_CN.properties ebba5e0 ui/dictionary.jsp 671f48f ui/scripts/network.js c27b999 ui/scripts/vpc.js af19d87 Diff: https://reviews.apache.org/r/28043/diff/ Testing --- Tests performed: - create new isolated network with DefaultIsolatedNetworkOffering, acquire new IP, list load balancer algorithms (UI) - create new shared network with DefaultSharedNetworkWithSourceNat, acquire new IP, list load balancer algorithms (UI) It should work correctly as long as network offering is configured with LB provider/capabilities. Otherwise, list of algorithms is empty in UI. Thanks, Daniel Vega Simoes
Re: Review Request 28043: CLOUDSTACK 7915: Remove hard-coded values for Load Balancer algorithms in UI
On Nov. 25, 2014, 8:15 a.m., Rajani Karuturi wrote: Ship It! pushed to 4.5 commit: ba6dfd84702eeef0362b94068add1328db84133a will merge to master as well - Rajani --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28043/#review62953 --- On Nov. 17, 2014, 6:26 p.m., Daniel Vega Simoes wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28043/ --- (Updated Nov. 17, 2014, 6:26 p.m.) Review request for cloudstack. Repository: cloudstack-git Description --- JIRA: CLOUDSTACK 7915 Removed hard-coded values for Load Balancer algorithms in UI. Instead, now UI sets values loaded dynamically through load balancer provider capabilities. Also updated internationalization messages. Diffs - client/WEB-INF/classes/resources/messages.properties 86eb5c2 client/WEB-INF/classes/resources/messages_ar.properties 4f65118 client/WEB-INF/classes/resources/messages_es.properties f2d754e client/WEB-INF/classes/resources/messages_fr_FR.properties 004187f client/WEB-INF/classes/resources/messages_it_IT.properties e2f3f0b client/WEB-INF/classes/resources/messages_ja_JP.properties 7bc90b5 client/WEB-INF/classes/resources/messages_ko_KR.properties ce79d2e client/WEB-INF/classes/resources/messages_nb_NO.properties c169112 client/WEB-INF/classes/resources/messages_nl_NL.properties 89ef828 client/WEB-INF/classes/resources/messages_pl.properties 06d5ec2 client/WEB-INF/classes/resources/messages_pt_BR.properties 8ee08ba client/WEB-INF/classes/resources/messages_ru_RU.properties ff68668 client/WEB-INF/classes/resources/messages_zh_CN.properties ebba5e0 ui/dictionary.jsp 671f48f ui/scripts/network.js c27b999 ui/scripts/vpc.js af19d87 Diff: https://reviews.apache.org/r/28043/diff/ Testing --- Tests performed: - create new isolated network with DefaultIsolatedNetworkOffering, acquire new IP, list load balancer algorithms (UI) - create new shared network with DefaultSharedNetworkWithSourceNat, acquire new IP, list load balancer algorithms (UI) It should work correctly as long as network offering is configured with LB provider/capabilities. Otherwise, list of algorithms is empty in UI. Thanks, Daniel Vega Simoes
Re: Review Request 28049: CLOUDSTACK-7917: Load Balancer Rule is not validated when updating LB
On Nov. 25, 2014, 8:14 a.m., Rajani Karuturi wrote: Ship It! Thanks for adding tests. pushed to 4.5 c919ff83d81528b89017b5f5731b2e46350e3dfa will merge to master as well. - Rajani --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28049/#review62950 --- On Nov. 24, 2014, 4:23 p.m., Daniel Vega Simoes wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28049/ --- (Updated Nov. 24, 2014, 4:23 p.m.) Review request for cloudstack. Repository: cloudstack-git Description --- JIRA: https://issues.apache.org/jira/browse/CLOUDSTACK-7917 Validate Load Balancer rule with provider before commiting to DB and applying new rule. Diffs - server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java a28d108 server/test/com/cloud/network/lb/UpdateLoadBalancerTest.java PRE-CREATION Diff: https://reviews.apache.org/r/28049/diff/ Testing --- Created 2 new unit tests that are located in server/test/com/cloud/network/lb/UpdateLoadBalancerTest.java - Test to guarantee that validate is being called when updating LB rule - Test to guarantee that it throws exception if LB rule is not validated by provider Ran integration tests (smoke), all seems OK. Thanks, Daniel Vega Simoes
Re: Review Request 20518: CLOUDSTACK-6465: vmware.reserve.mem is missing from cluster level settings
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20518/#review62955 --- Ship it! Ship It! - Rajani Karuturi On Nov. 25, 2014, 6:06 a.m., Harikrishna Patnala wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20518/ --- (Updated Nov. 25, 2014, 6:06 a.m.) Review request for cloudstack, Kishan Kavala and Rajani Karuturi. Bugs: CLOUDSTACK-6465 https://issues.apache.org/jira/browse/CLOUDSTACK-6465 Repository: cloudstack-git Description --- CLOUDSTACK-6465: vmware.reserve.mem is missing from cluster level settings Diffs - plugins/hypervisors/vmware/src/com/cloud/hypervisor/guru/VMwareGuru.java 7c23699 plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareManagerImpl.java 4f24882 plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java e3bfbe5 server/src/com/cloud/configuration/Config.java 5ac0e90 Diff: https://reviews.apache.org/r/20518/diff/ Testing --- Thanks, Harikrishna Patnala
Re: Review Request 20518: CLOUDSTACK-6465: vmware.reserve.mem is missing from cluster level settings
On Nov. 25, 2014, 8:16 a.m., Rajani Karuturi wrote: Ship It! pushed to 4.5. commit eae733817b3670b0151410c027325f78013392ad will merge to master as well. - Rajani --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20518/#review62955 --- On Nov. 25, 2014, 6:06 a.m., Harikrishna Patnala wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20518/ --- (Updated Nov. 25, 2014, 6:06 a.m.) Review request for cloudstack, Kishan Kavala and Rajani Karuturi. Bugs: CLOUDSTACK-6465 https://issues.apache.org/jira/browse/CLOUDSTACK-6465 Repository: cloudstack-git Description --- CLOUDSTACK-6465: vmware.reserve.mem is missing from cluster level settings Diffs - plugins/hypervisors/vmware/src/com/cloud/hypervisor/guru/VMwareGuru.java 7c23699 plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareManagerImpl.java 4f24882 plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java e3bfbe5 server/src/com/cloud/configuration/Config.java 5ac0e90 Diff: https://reviews.apache.org/r/20518/diff/ Testing --- Thanks, Harikrishna Patnala
Re: Review Request 17941: CLOUDSTACK-6075: Increase the ram size for router service offering
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17941/#review62957 --- I tried to merge it on 4.5/master, there were few issues. There is a PR to merge 4.5 on master, so you may need to redo the patch once that is done. - Rohit Yadav On Nov. 25, 2014, 6:07 a.m., Harikrishna Patnala wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17941/ --- (Updated Nov. 25, 2014, 6:07 a.m.) Review request for cloudstack, Jayapal Reddy, Kishan Kavala, and Rajani Karuturi. Bugs: CLOUDSTACK-6075 https://issues.apache.org/jira/browse/CLOUDSTACK-6075 Repository: cloudstack-git Description --- CLOUDSTACK-6075: Increase the ram size for router service offering Increased the ram size of Internal load balancer vm service offering also Diffs - engine/schema/src/com/cloud/upgrade/dao/Upgrade441to450.java cde661b plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManager.java 803d3a5 server/src/com/cloud/configuration/Config.java 517c76c server/src/com/cloud/network/router/VirtualNetworkApplianceManager.java 85ce8b9 setup/db/db/schema-441to450.sql c899289 Diff: https://reviews.apache.org/r/17941/diff/ Testing --- tested locally Thanks, Harikrishna Patnala
Re: Review Request 17941: CLOUDSTACK-6075: Increase the ram size for router service offering
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17941/#review62958 --- LGTM. - Rohit Yadav On Nov. 25, 2014, 6:07 a.m., Harikrishna Patnala wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17941/ --- (Updated Nov. 25, 2014, 6:07 a.m.) Review request for cloudstack, Jayapal Reddy, Kishan Kavala, and Rajani Karuturi. Bugs: CLOUDSTACK-6075 https://issues.apache.org/jira/browse/CLOUDSTACK-6075 Repository: cloudstack-git Description --- CLOUDSTACK-6075: Increase the ram size for router service offering Increased the ram size of Internal load balancer vm service offering also Diffs - engine/schema/src/com/cloud/upgrade/dao/Upgrade441to450.java cde661b plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManager.java 803d3a5 server/src/com/cloud/configuration/Config.java 517c76c server/src/com/cloud/network/router/VirtualNetworkApplianceManager.java 85ce8b9 setup/db/db/schema-441to450.sql c899289 Diff: https://reviews.apache.org/r/17941/diff/ Testing --- tested locally Thanks, Harikrishna Patnala
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Good ideas, I’ll use them. So I think no one disagrees with this; - list VMs still has user_id, but deployVM won’t - We’ll use first user in the account if someone’s impersonating; else use logged in user to get user_id On 25-Nov-2014, at 12:17 am, Prachi Damle prachi.da...@citrix.com wrote: Hi Rohit, I see your point: when deploy VM is called by an admin impersonating another account, the user_id value will be set to logged in user, which will be the admin. And this will break your usecase. Correct? Do you think your functionality needs this usecase i.e an admin impersonating deployVm for another user? If you won't hit this scenario primarily, we can just set the user_id to first user in the account being impersonated to cover this case - just as your upgrade code for existing Vms. What do you think? Thanks, Prachi -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Friday, November 21, 2014 11:13 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Hi Min, Prachi, Thanks for your comments. I see your point, the use case is to list VMs for a user_id (uuid, not name). I'm going to add the arg/option the listVM api to accept user_id and return the list of VMs for that user, and add option in the UI to do the same. Note, this is not for auditing purposes (for that we have events). But, since we allow impersonation of account while deploying a VM by the same logic we should allow impersonation at the user_id as well which we only accept in the deploy VM API if an account/domain is mentioned along with the user_id. If I only use logged-in user ID, it makes implementation very simple but at the same time but sort of breaks impersonation semantics. Note: the fix will be simple, won't change IAM and this is just to add capability to list VMs for a user ID. On 21-Nov-2014, at 11:57 pm, Prachi Damle prachi.da...@citrix.com wrote: Hi Rohit, The accountId in deployVm API is serving the purpose of impersonation and can be passed typically by admin accounts to deploy VM on behalf of other User. So Ideally with IAM, this parameter should be removed from the API and impersonation should be handled separately. Keeping this goal, I think let's not add userID parameter in the API. We should default the value to the logged in user - this will prevent usecases around cross-account/cross-user scenarios. Thanks, Prachi -Original Message- From: Min Chen [mailto:min.c...@citrix.com] Sent: Friday, November 21, 2014 8:16 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount If I understood correctly, (account, domainId) passed into deployVMCmd is used for impersonation-like behavior, that is, caller is deploying a VM on behalf of an account. Personally I don't like this kind of putting so many parameters in one API to perform several different functionalities, impersonation should be done through IAM separately. Too many parameters will just make our API semantics very hard to understand and maintain. Along this line, I will not like to see this user_id added here. Thanks -min On 11/21/14 5:20 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Prachi, Since we¹re already allowing users to specific account and list VMs by account, following the same pattern I added the case so as to allow users to specify user_id in both list/deploy VM commands. In case the userid is not specified, in that case the logged in user¹s ID will be used. It¹s open for discussion of course, let me know if it¹s a good idea to follow the same pattern or strictly use the logged-in user¹s ID? On 21-Nov-2014, at 1:41 am, Prachi Damle prachi.da...@citrix.com wrote: Rohit, I checked the code here https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog; h= ref s/heads/useraccount-refactoring and I don't understand why we need to expose the userId parameter in the deployVm API. I think we should be using the userId of the logged in user always. Exposing the parameter at the API allows it to be set by a user to the ID of another user . Also we need validation around it to make sure it belongs to the passed account etc. +//Owner userId +@Parameter(name = ApiConstants.USER_ID, type = + CommandType.UUID, entityType = UserResponse.class, required = true, description = the user ID of the owner, optional to use with account and domainId. If not provided logged in user's ID is used.) +private Long userId; Prachi -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Sunday, November 16, 2014 6:06 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Only one table will be affected. On 16-Nov-2014, at 3:14 am, Amogh
Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)
Anybody else seeing this? @Ian, please confirm this is a regression compared to 4.4.1. Ans can you describe the scenario/is this a regular template test or a systemvm template? I will not regard this a blocker without confirmation. We have enough +1 binding but I will extend voting a bit. Daan On Mon, Nov 24, 2014 at 8:01 PM, Ian Duffy i...@ianduffy.ie wrote: +0 (Don't want to get in the way...) Tested with my standard automated virtualised cloudstack environment. Failed to import a template successfully. The template downloaded, it hung on installing template for awhile eventually got an error of Failed post download script: timeout The logs repeat the following over and over: INFO [c.c.a.m.AgentManagerImpl] (AgentMonitor-1:ctx-0209bee9) Found the following agents behind on ping: [1] INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-12:ctx-c5084767) Investigating why host 1 has disconnected with event PingTimeout INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-12:ctx-c5084767) The state determined is Up INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-12:ctx-c5084767) Agent is determined to be up and running WARN [c.c.a.m.DirectAgentAttache] (DirectAgentCronJob-15:ctx-b3fbf6da) Unable to get current status on 1(localhost.localdomain) I don't appear to have any network issues with the hypervisor from the management server. The system vms booted up just fine and look healthy. The API params for configuring xenserver advanced networking tags are still different thus breaking marvin. On 24 November 2014 at 13:05, Wido den Hollander w...@widodh.nl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 (binding) I've tested: - - Building the .deb packages - - Upgrading a KVM setup from 4.4.1 Wido On 11/21/2014 03:59 AM, Daan Hoogland wrote: Hi All, I've created a 4.4.2 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4 Commit: e0420a6fec738d728bc59ba65bc5e12809bde0eb List of changes: `CLOUDSTACK-7887 https://issues.apache.org/jira/browse/CLOUDSTACK-7887`_ fail to push snapshot to secondary storage if using multipart using swift... `CLOUDSTACK-7883 https://issues.apache.org/jira/browse/CLOUDSTACK-7883`_ Allow infrastructure to handle delete of volume from DB... `CLOUDSTACK-7871 https://issues.apache.org/jira/browse/CLOUDSTACK-7871`_ Fix update VirtualMachine/Template API to allow nic/disk controller details for ... `CLOUDSTACK-7855 https://issues.apache.org/jira/browse/CLOUDSTACK-7855`_ Sec storage/network MTU should be on nic3 and not nic1... `CLOUDSTACK-7826 https://issues.apache.org/jira/browse/CLOUDSTACK-7826`_ UI - dialog widget - dependent dropdown field (dependsOn property specified) - f... `CLOUDSTACK-7822 https://issues.apache.org/jira/browse/CLOUDSTACK-7822`_ test SSL cert expired... `CLOUDSTACK-7752 https://issues.apache.org/jira/browse/CLOUDSTACK-7752`_ Management Server goes in infinite loop while creating a vm with tagged local da... `CLOUDSTACK-7722 https://issues.apache.org/jira/browse/CLOUDSTACK-7722`_ add.label: Add button for tags show the label not Add text... `CLOUDSTACK-7246 https://issues.apache.org/jira/browse/CLOUDSTACK-7246`_ VM deployment failed due to wrong in script name createipalias.sh... Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.4.2 PGP release keys (signed using 4096R/AA4736F3): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Vote will be open for 72 hours. For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUcy0eAAoJEAGbWC3bPspCcxkQAID1eLD8ZykVdlwnQMt9w6XW SFZ64vXgC97EAaQKSvAJ/I9arUIxq0itpe/WOplqQprlTPgheY6eK4I8O84+XzES RfZbFz6q2BSNtpr6x6+roE7F+EvLJhmw9QXwDvKTJAnl5BYbqiBrffxw/wXigYm1 7NGu5+LOnQXvNgX6nWt3+voP4p+cL9u3OIMy4KUsaFLEpoeG63H7N0w5aaAPmNni 8XjKWOmJP7OV05fsfus/Oppd/XFmvuvzjOwRDbe+Tzm/OQFCB7fDG2MYPAs9GqRj Nj9VmRyX1iTel6Qn+1MGGHWANKlv4+c0IRkmqXObf7wzE2bNq831HqN8+53mR7JZ fd/1RIX47s9xYhhPzeORFy1hIHJiZ0GnwZGE789hTIhjziCRjKOquN0sfj2VsHuB a4B14COmlGXdJmRM3X5y/Qq0b25/nO89pcN1S04HIvSCqUz/R5GMX+vlMG/cC05u XNmFvsLi+NtVlOrkSAXJEhq5k+og8c0+PmFCaqfqbO/GS7uIa0Ciy0w4fvsSWf7e u/2dr4hmI1WMtJfF/exXZmb8Ht4FtLzLXfgr05J3rw65FMLKHZojBxgKuBEkQN3d ii59k4Wjyds+64cofz88KrAvWycLF6M7YttZ/dDQQnUKmcIVDec5b1d/xia3xjXw 60qLY0GBqgbYPKX+Q+cL =Tdvh -END PGP SIGNATURE- -- Daan
Re: [GitHub] cloudstack pull request: Merge 4.5 to master
Thanks for keeping at it Rajani, I gave up yesterday on merging the 4.4.2 to 4.5.0 upgrade code after it resulted in a merge mess. These changes are not in your pull request (yet?). Also I see travis failures mentioned. So I think we are not ready for this. The upgrade code contained quite some doublures and my cleanup will result in merge conflicts. I am about to port my build_asf.sh adjustments to 4.5. On Tue, Nov 25, 2014 at 7:18 AM, karuturi g...@git.apache.org wrote: GitHub user karuturi opened a pull request: https://github.com/apache/cloudstack/pull/45 Merge 4.5 to master You can merge this pull request into a Git repository by running: $ git pull https://github.com/karuturi/cloudstack merge45-to-master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/45.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #45 commit 2d3b3376e37faeec3ed62a58750819dc7630260c Author: Sheng Yang sheng.y...@citrix.com Date: 2014-11-14T19:43:03Z Revert CLOUDSTACK-7821: Fix OSX cannot connect to VPN due to wrongly declaim ENCAPSULATION_MODE_UDP_TRANSPORT_RFC This reverts commit e1c788ca3c69a8c8c2041c7b106f76fa49332888. It breaks Windows 7 client. commit 425a6b01d60b88016c23a1126960375b00d97069 Author: Anthony Xu anthony...@citrix.com Date: 2014-11-14T19:24:42Z CLOUDSTACK-7918: guest os name changes from 'SUSE Linux Enterprise Server 12 (experimental)' to 'SUSE Linux Enterprise Server 12 (64-bit)' in latest XS 5.6 , changed the guest OS mapping to fix it. commit 303fc90057db2707ae8f6b709fb5e3e86fc9db40 Author: Milamber milam...@apache.org Date: 2014-11-15T08:37:49Z Update L10N resource files on master branch (with 4.5 translation strings) commit 25e5d00f6016b31fc178da97c7125c2f37a8c40d Author: Milamber milam...@apache.org Date: 2014-11-15T08:38:34Z Add 4.5.x messages.properties to Transifex config tool commit 19781e094b987cf65d05d890cd3cd86fc22cb873 Author: Chandan Purushothama chandan.purushoth...@citrix.com Date: 2014-11-14T06:56:01Z CLOUDSTACK-7913 : Added reconnect functionality to Host class in base.py Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org commit 5f99917991a59f8ecd6d8b0e17b497fe210e636e Author: Gaurav Aradhye gaurav.arad...@clogeny.com Date: 2014-11-14T14:23:25Z CLOUDSTACK-7912: Remove hardcoded netscaler info and read it from config file Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org commit 635abaf2e9ca4f0399085f441ea6d5eeaab9f3ab Author: Jessica Wang jessicaw...@apache.org Date: 2014-11-17T21:05:08Z CLOUDSTACK-7927: UI Infrastructure Primary Storage detailView add View Volumes link that will list all volumes under this primary storage when being clicked. commit f43ffb9a0f71f380f896e1e5c581725e9c08faab Author: Anshul Gangwar anshul.gang...@citrix.com Date: 2014-10-09T05:07:21Z CLOUDSTACK-7688, CLOUDSTACK-7747: restricted various operations for VM with VM snapshots which breaks VM snapshots. Now they are informed that they cannot perform the operation. To perform operation they have to remove VM snapshots of VM. commit c04cdae60bc9a10f584c2f0b591aa5a5d9c7e3e4 Author: Anshul Gangwar anshul.gang...@citrix.com Date: 2014-10-28T06:19:30Z CLOUDSTACK-7767: fixed events are not generated for snapshot creation commit ae199b6ce7634ef702243c20800937c8a3ab4b14 Author: Anshul Gangwar anshul.gang...@citrix.com Date: 2014-10-20T10:34:25Z CLOUDSTACK-7703, CLOUDSTACK-7752: Fixed deployment planner stuck in infinite loop. If we create VM with shared service offering and attach disk with local disk offering, and one of storage pool is full(cannot be allocated) and other is not full then we are not putting the cluster in avoid list which is causing this infinite loop. Fixed by putting the cluster in avoid list even if one of the storage pool is full(cannot be allocated) commit bcc20380680a84f7975f75aa8c6ebdaadb1f8540 Author: Anshul Gangwar anshul.gang...@citrix.com Date: 2014-09-24T07:20:16Z CLOUDSTACK-7620: Added SNMP MIB file for snmp-alerts plugin commit 44d12330b9d7494ad392e0549ffbdc7100130f86 Author: Anshul Gangwar anshul.gang...@citrix.com Date: 2014-10-21T09:27:16Z CLOUDSTACK-7758: Fixed although api calls are failing, event tab shows them as successful This closes #29 commit 4721e66d0e2ed89836286f1654a30a3568b284b6 Author: Anshul Gangwar anshul.gang...@citrix.com Date: 2014-10-22T04:29:42Z CLOUDSTACK-7541: Added restriction to not allow custom disk offering with disksize UI doesn't allow but with API we were able to create custom disk offering with disk size which was causing this issue This closes #28 commit
Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)
I'll upgrade my test setup (4.4.1) today and get back to you. Do I need a new systemvm or can I just leave the old one from 4.4.1 in place? -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Daan Hoogland daan.hoogl...@gmail.com To: dev dev@cloudstack.apache.org, Ian Duffy i...@ianduffy.ie Sent: Tuesday, 25 November, 2014 09:37:36 Subject: Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2) Anybody else seeing this? @Ian, please confirm this is a regression compared to 4.4.1. Ans can you describe the scenario/is this a regular template test or a systemvm template? I will not regard this a blocker without confirmation. We have enough +1 binding but I will extend voting a bit. Daan On Mon, Nov 24, 2014 at 8:01 PM, Ian Duffy i...@ianduffy.ie wrote: +0 (Don't want to get in the way...) Tested with my standard automated virtualised cloudstack environment. Failed to import a template successfully. The template downloaded, it hung on installing template for awhile eventually got an error of Failed post download script: timeout The logs repeat the following over and over: INFO [c.c.a.m.AgentManagerImpl] (AgentMonitor-1:ctx-0209bee9) Found the following agents behind on ping: [1] INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-12:ctx-c5084767) Investigating why host 1 has disconnected with event PingTimeout INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-12:ctx-c5084767) The state determined is Up INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-12:ctx-c5084767) Agent is determined to be up and running WARN [c.c.a.m.DirectAgentAttache] (DirectAgentCronJob-15:ctx-b3fbf6da) Unable to get current status on 1(localhost.localdomain) I don't appear to have any network issues with the hypervisor from the management server. The system vms booted up just fine and look healthy. The API params for configuring xenserver advanced networking tags are still different thus breaking marvin. On 24 November 2014 at 13:05, Wido den Hollander w...@widodh.nl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 (binding) I've tested: - - Building the .deb packages - - Upgrading a KVM setup from 4.4.1 Wido On 11/21/2014 03:59 AM, Daan Hoogland wrote: Hi All, I've created a 4.4.2 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4 Commit: e0420a6fec738d728bc59ba65bc5e12809bde0eb List of changes: `CLOUDSTACK-7887 https://issues.apache.org/jira/browse/CLOUDSTACK-7887`_ fail to push snapshot to secondary storage if using multipart using swift... `CLOUDSTACK-7883 https://issues.apache.org/jira/browse/CLOUDSTACK-7883`_ Allow infrastructure to handle delete of volume from DB... `CLOUDSTACK-7871 https://issues.apache.org/jira/browse/CLOUDSTACK-7871`_ Fix update VirtualMachine/Template API to allow nic/disk controller details for ... `CLOUDSTACK-7855 https://issues.apache.org/jira/browse/CLOUDSTACK-7855`_ Sec storage/network MTU should be on nic3 and not nic1... `CLOUDSTACK-7826 https://issues.apache.org/jira/browse/CLOUDSTACK-7826`_ UI - dialog widget - dependent dropdown field (dependsOn property specified) - f... `CLOUDSTACK-7822 https://issues.apache.org/jira/browse/CLOUDSTACK-7822`_ test SSL cert expired... `CLOUDSTACK-7752 https://issues.apache.org/jira/browse/CLOUDSTACK-7752`_ Management Server goes in infinite loop while creating a vm with tagged local da... `CLOUDSTACK-7722 https://issues.apache.org/jira/browse/CLOUDSTACK-7722`_ add.label: Add button for tags show the label not Add text... `CLOUDSTACK-7246 https://issues.apache.org/jira/browse/CLOUDSTACK-7246`_ VM deployment failed due to wrong in script name createipalias.sh... Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.4.2 PGP release keys (signed using 4096R/AA4736F3): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Vote will be open for 72 hours. For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUcy0eAAoJEAGbWC3bPspCcxkQAID1eLD8ZykVdlwnQMt9w6XW SFZ64vXgC97EAaQKSvAJ/I9arUIxq0itpe/WOplqQprlTPgheY6eK4I8O84+XzES RfZbFz6q2BSNtpr6x6+roE7F+EvLJhmw9QXwDvKTJAnl5BYbqiBrffxw/wXigYm1 7NGu5+LOnQXvNgX6nWt3+voP4p+cL9u3OIMy4KUsaFLEpoeG63H7N0w5aaAPmNni 8XjKWOmJP7OV05fsfus/Oppd/XFmvuvzjOwRDbe+Tzm/OQFCB7fDG2MYPAs9GqRj Nj9VmRyX1iTel6Qn+1MGGHWANKlv4+c0IRkmqXObf7wzE2bNq831HqN8+53mR7JZ fd/1RIX47s9xYhhPzeORFy1hIHJiZ0GnwZGE789hTIhjziCRjKOquN0sfj2VsHuB a4B14COmlGXdJmRM3X5y/Qq0b25/nO89pcN1S04HIvSCqUz/R5GMX+vlMG/cC05u
Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)
Thanks Lucian, I am not sure what Ians failing scenario is? It might be the download process that is failing and it might be the starting. On Tue, Nov 25, 2014 at 11:05 AM, Nux! n...@li.nux.ro wrote: I'll upgrade my test setup (4.4.1) today and get back to you. Do I need a new systemvm or can I just leave the old one from 4.4.1 in place? -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Daan Hoogland daan.hoogl...@gmail.com To: dev dev@cloudstack.apache.org, Ian Duffy i...@ianduffy.ie Sent: Tuesday, 25 November, 2014 09:37:36 Subject: Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2) Anybody else seeing this? @Ian, please confirm this is a regression compared to 4.4.1. Ans can you describe the scenario/is this a regular template test or a systemvm template? I will not regard this a blocker without confirmation. We have enough +1 binding but I will extend voting a bit. Daan On Mon, Nov 24, 2014 at 8:01 PM, Ian Duffy i...@ianduffy.ie wrote: +0 (Don't want to get in the way...) Tested with my standard automated virtualised cloudstack environment. Failed to import a template successfully. The template downloaded, it hung on installing template for awhile eventually got an error of Failed post download script: timeout The logs repeat the following over and over: INFO [c.c.a.m.AgentManagerImpl] (AgentMonitor-1:ctx-0209bee9) Found the following agents behind on ping: [1] INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-12:ctx-c5084767) Investigating why host 1 has disconnected with event PingTimeout INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-12:ctx-c5084767) The state determined is Up INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-12:ctx-c5084767) Agent is determined to be up and running WARN [c.c.a.m.DirectAgentAttache] (DirectAgentCronJob-15:ctx-b3fbf6da) Unable to get current status on 1(localhost.localdomain) I don't appear to have any network issues with the hypervisor from the management server. The system vms booted up just fine and look healthy. The API params for configuring xenserver advanced networking tags are still different thus breaking marvin. -- Daan
Review Request 28437: CLOUDSTACK-6282 Added automated ACL tests
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28437/ --- 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 ACL tests Diffs - test/integration/component/test_escalations_networks.py fb2196c Diff: https://reviews.apache.org/r/28437/diff/ Testing --- Tests the changed files and attached are the results for the same File Attachments results.txt https://reviews.apache.org/media/uploaded/files/2014/11/25/61351189-70e9-4fa6-8bcf-035d28fa61e6__results.txt Thanks, anusha bilgi
Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)
Hi Daan, It was the importing of a standard template added via the UI. I will re-try again today to ensure it wasn't a networking fault (unlikely) but the messages about the host disconnecting randomly does have me concerned. I was using the system vm template from jenkins. http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-systemvm64/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-4.4-2014-11-24-xen.vhd.bz2 On 25 November 2014 at 10:11, Daan Hoogland daan.hoogl...@gmail.com wrote: Thanks Lucian, I am not sure what Ians failing scenario is? It might be the download process that is failing and it might be the starting. On Tue, Nov 25, 2014 at 11:05 AM, Nux! n...@li.nux.ro wrote: I'll upgrade my test setup (4.4.1) today and get back to you. Do I need a new systemvm or can I just leave the old one from 4.4.1 in place? -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Daan Hoogland daan.hoogl...@gmail.com To: dev dev@cloudstack.apache.org, Ian Duffy i...@ianduffy.ie Sent: Tuesday, 25 November, 2014 09:37:36 Subject: Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2) Anybody else seeing this? @Ian, please confirm this is a regression compared to 4.4.1. Ans can you describe the scenario/is this a regular template test or a systemvm template? I will not regard this a blocker without confirmation. We have enough +1 binding but I will extend voting a bit. Daan On Mon, Nov 24, 2014 at 8:01 PM, Ian Duffy i...@ianduffy.ie wrote: +0 (Don't want to get in the way...) Tested with my standard automated virtualised cloudstack environment. Failed to import a template successfully. The template downloaded, it hung on installing template for awhile eventually got an error of Failed post download script: timeout The logs repeat the following over and over: INFO [c.c.a.m.AgentManagerImpl] (AgentMonitor-1:ctx-0209bee9) Found the following agents behind on ping: [1] INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-12:ctx-c5084767) Investigating why host 1 has disconnected with event PingTimeout INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-12:ctx-c5084767) The state determined is Up INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-12:ctx-c5084767) Agent is determined to be up and running WARN [c.c.a.m.DirectAgentAttache] (DirectAgentCronJob-15:ctx-b3fbf6da) Unable to get current status on 1(localhost.localdomain) I don't appear to have any network issues with the hypervisor from the management server. The system vms booted up just fine and look healthy. The API params for configuring xenserver advanced networking tags are still different thus breaking marvin. -- Daan
Re: Review Request 28049: CLOUDSTACK-7917: Load Balancer Rule is not validated when updating LB
On Nov. 25, 2014, 8:14 a.m., Rajani Karuturi wrote: Ship It! Rajani Karuturi wrote: Thanks for adding tests. pushed to 4.5 c919ff83d81528b89017b5f5731b2e46350e3dfa will merge to master as well. master 02ca6f2e5b7d8ffdc917ed09d8600c38e668ea17 - Rajani --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28049/#review62950 --- On Nov. 24, 2014, 4:23 p.m., Daniel Vega Simoes wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28049/ --- (Updated Nov. 24, 2014, 4:23 p.m.) Review request for cloudstack. Repository: cloudstack-git Description --- JIRA: https://issues.apache.org/jira/browse/CLOUDSTACK-7917 Validate Load Balancer rule with provider before commiting to DB and applying new rule. Diffs - server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java a28d108 server/test/com/cloud/network/lb/UpdateLoadBalancerTest.java PRE-CREATION Diff: https://reviews.apache.org/r/28049/diff/ Testing --- Created 2 new unit tests that are located in server/test/com/cloud/network/lb/UpdateLoadBalancerTest.java - Test to guarantee that validate is being called when updating LB rule - Test to guarantee that it throws exception if LB rule is not validated by provider Ran integration tests (smoke), all seems OK. Thanks, Daniel Vega Simoes
Re: Review Request 28043: CLOUDSTACK 7915: Remove hard-coded values for Load Balancer algorithms in UI
On Nov. 25, 2014, 8:15 a.m., Rajani Karuturi wrote: Ship It! Rajani Karuturi wrote: pushed to 4.5 commit: ba6dfd84702eeef0362b94068add1328db84133a will merge to master as well master 93f82134129756946dabf90f05262cccb576d33c - Rajani --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28043/#review62953 --- On Nov. 17, 2014, 6:26 p.m., Daniel Vega Simoes wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28043/ --- (Updated Nov. 17, 2014, 6:26 p.m.) Review request for cloudstack. Repository: cloudstack-git Description --- JIRA: CLOUDSTACK 7915 Removed hard-coded values for Load Balancer algorithms in UI. Instead, now UI sets values loaded dynamically through load balancer provider capabilities. Also updated internationalization messages. Diffs - client/WEB-INF/classes/resources/messages.properties 86eb5c2 client/WEB-INF/classes/resources/messages_ar.properties 4f65118 client/WEB-INF/classes/resources/messages_es.properties f2d754e client/WEB-INF/classes/resources/messages_fr_FR.properties 004187f client/WEB-INF/classes/resources/messages_it_IT.properties e2f3f0b client/WEB-INF/classes/resources/messages_ja_JP.properties 7bc90b5 client/WEB-INF/classes/resources/messages_ko_KR.properties ce79d2e client/WEB-INF/classes/resources/messages_nb_NO.properties c169112 client/WEB-INF/classes/resources/messages_nl_NL.properties 89ef828 client/WEB-INF/classes/resources/messages_pl.properties 06d5ec2 client/WEB-INF/classes/resources/messages_pt_BR.properties 8ee08ba client/WEB-INF/classes/resources/messages_ru_RU.properties ff68668 client/WEB-INF/classes/resources/messages_zh_CN.properties ebba5e0 ui/dictionary.jsp 671f48f ui/scripts/network.js c27b999 ui/scripts/vpc.js af19d87 Diff: https://reviews.apache.org/r/28043/diff/ Testing --- Tests performed: - create new isolated network with DefaultIsolatedNetworkOffering, acquire new IP, list load balancer algorithms (UI) - create new shared network with DefaultSharedNetworkWithSourceNat, acquire new IP, list load balancer algorithms (UI) It should work correctly as long as network offering is configured with LB provider/capabilities. Otherwise, list of algorithms is empty in UI. Thanks, Daniel Vega Simoes
Re: Review Request 20518: CLOUDSTACK-6465: vmware.reserve.mem is missing from cluster level settings
On Nov. 25, 2014, 8:16 a.m., Rajani Karuturi wrote: Ship It! Rajani Karuturi wrote: pushed to 4.5. commit eae733817b3670b0151410c027325f78013392ad will merge to master as well. master 9585aa0b51a571d5ea3c33c98bec13f5230ecf4a - Rajani --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20518/#review62955 --- On Nov. 25, 2014, 6:06 a.m., Harikrishna Patnala wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/20518/ --- (Updated Nov. 25, 2014, 6:06 a.m.) Review request for cloudstack, Kishan Kavala and Rajani Karuturi. Bugs: CLOUDSTACK-6465 https://issues.apache.org/jira/browse/CLOUDSTACK-6465 Repository: cloudstack-git Description --- CLOUDSTACK-6465: vmware.reserve.mem is missing from cluster level settings Diffs - plugins/hypervisors/vmware/src/com/cloud/hypervisor/guru/VMwareGuru.java 7c23699 plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareManagerImpl.java 4f24882 plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java e3bfbe5 server/src/com/cloud/configuration/Config.java 5ac0e90 Diff: https://reviews.apache.org/r/20518/diff/ Testing --- Thanks, Harikrishna Patnala
[GitHub] cloudstack pull request: Merge 4.5 to master
Github user karuturi closed the pull request at: https://github.com/apache/cloudstack/pull/45 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: [GitHub] cloudstack pull request: Merge 4.5 to master
Hi Daan, It had your upgrade changes(a52fd08a142edc6a62e43838113bc504c225fa11). It gave me some merge conflicts and resolved them in favour of master as the changes are already there on master. Checking the travis build history shows that there are failures in the past builds as well. It may not be this merge but, didnt want to take chances. Discarded the merge request for now :( Will attempt another merge later. ~Rajani On Tue, Nov 25, 2014 at 3:34 PM, Daan Hoogland daan.hoogl...@gmail.com wrote: Thanks for keeping at it Rajani, I gave up yesterday on merging the 4.4.2 to 4.5.0 upgrade code after it resulted in a merge mess. These changes are not in your pull request (yet?). Also I see travis failures mentioned. So I think we are not ready for this. The upgrade code contained quite some doublures and my cleanup will result in merge conflicts. I am about to port my build_asf.sh adjustments to 4.5. On Tue, Nov 25, 2014 at 7:18 AM, karuturi g...@git.apache.org wrote: GitHub user karuturi opened a pull request: https://github.com/apache/cloudstack/pull/45 Merge 4.5 to master You can merge this pull request into a Git repository by running: $ git pull https://github.com/karuturi/cloudstack merge45-to-master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/45.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #45 commit 2d3b3376e37faeec3ed62a58750819dc7630260c Author: Sheng Yang sheng.y...@citrix.com Date: 2014-11-14T19:43:03Z Revert CLOUDSTACK-7821: Fix OSX cannot connect to VPN due to wrongly declaim ENCAPSULATION_MODE_UDP_TRANSPORT_RFC This reverts commit e1c788ca3c69a8c8c2041c7b106f76fa49332888. It breaks Windows 7 client. commit 425a6b01d60b88016c23a1126960375b00d97069 Author: Anthony Xu anthony...@citrix.com Date: 2014-11-14T19:24:42Z CLOUDSTACK-7918: guest os name changes from 'SUSE Linux Enterprise Server 12 (experimental)' to 'SUSE Linux Enterprise Server 12 (64-bit)' in latest XS 5.6 , changed the guest OS mapping to fix it. commit 303fc90057db2707ae8f6b709fb5e3e86fc9db40 Author: Milamber milam...@apache.org Date: 2014-11-15T08:37:49Z Update L10N resource files on master branch (with 4.5 translation strings) commit 25e5d00f6016b31fc178da97c7125c2f37a8c40d Author: Milamber milam...@apache.org Date: 2014-11-15T08:38:34Z Add 4.5.x messages.properties to Transifex config tool commit 19781e094b987cf65d05d890cd3cd86fc22cb873 Author: Chandan Purushothama chandan.purushoth...@citrix.com Date: 2014-11-14T06:56:01Z CLOUDSTACK-7913 : Added reconnect functionality to Host class in base.py Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org commit 5f99917991a59f8ecd6d8b0e17b497fe210e636e Author: Gaurav Aradhye gaurav.arad...@clogeny.com Date: 2014-11-14T14:23:25Z CLOUDSTACK-7912: Remove hardcoded netscaler info and read it from config file Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org commit 635abaf2e9ca4f0399085f441ea6d5eeaab9f3ab Author: Jessica Wang jessicaw...@apache.org Date: 2014-11-17T21:05:08Z CLOUDSTACK-7927: UI Infrastructure Primary Storage detailView add View Volumes link that will list all volumes under this primary storage when being clicked. commit f43ffb9a0f71f380f896e1e5c581725e9c08faab Author: Anshul Gangwar anshul.gang...@citrix.com Date: 2014-10-09T05:07:21Z CLOUDSTACK-7688, CLOUDSTACK-7747: restricted various operations for VM with VM snapshots which breaks VM snapshots. Now they are informed that they cannot perform the operation. To perform operation they have to remove VM snapshots of VM. commit c04cdae60bc9a10f584c2f0b591aa5a5d9c7e3e4 Author: Anshul Gangwar anshul.gang...@citrix.com Date: 2014-10-28T06:19:30Z CLOUDSTACK-7767: fixed events are not generated for snapshot creation commit ae199b6ce7634ef702243c20800937c8a3ab4b14 Author: Anshul Gangwar anshul.gang...@citrix.com Date: 2014-10-20T10:34:25Z CLOUDSTACK-7703, CLOUDSTACK-7752: Fixed deployment planner stuck in infinite loop. If we create VM with shared service offering and attach disk with local disk offering, and one of storage pool is full(cannot be allocated) and other is not full then we are not putting the cluster in avoid list which is causing this infinite loop. Fixed by putting the cluster in avoid list even if one of the storage pool is full(cannot be allocated) commit bcc20380680a84f7975f75aa8c6ebdaadb1f8540 Author: Anshul Gangwar anshul.gang...@citrix.com Date: 2014-09-24T07:20:16Z CLOUDSTACK-7620: Added SNMP MIB file for snmp-alerts plugin commit
Jenkins build is still unstable: simulator-singlerun #692
See http://jenkins.buildacloud.org/job/simulator-singlerun/changes
Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)
Yes, there are so many wheels spinning... Anyway, +1 from me, `yum update` went fine on both agent and management (CentOS/KVM setup) from 4.4.1. Killed a couple of systemVMs which regenerated fine, registered a new template[1] and deployed an instance, all went OK. [1] - http://dl.openvm.eu/cloudstack/openbsd/vanilla/5.5/x86_64/openbsd55-8G-TESTING-kvm.qcow2.bz2 -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Daan Hoogland daan.hoogl...@gmail.com To: dev dev@cloudstack.apache.org Cc: Ian Duffy i...@ianduffy.ie Sent: Tuesday, 25 November, 2014 10:11:11 Subject: Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2) Thanks Lucian, I am not sure what Ians failing scenario is? It might be the download process that is failing and it might be the starting. On Tue, Nov 25, 2014 at 11:05 AM, Nux! n...@li.nux.ro wrote: I'll upgrade my test setup (4.4.1) today and get back to you. Do I need a new systemvm or can I just leave the old one from 4.4.1 in place? -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Daan Hoogland daan.hoogl...@gmail.com To: dev dev@cloudstack.apache.org, Ian Duffy i...@ianduffy.ie Sent: Tuesday, 25 November, 2014 09:37:36 Subject: Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2) Anybody else seeing this? @Ian, please confirm this is a regression compared to 4.4.1. Ans can you describe the scenario/is this a regular template test or a systemvm template? I will not regard this a blocker without confirmation. We have enough +1 binding but I will extend voting a bit. Daan On Mon, Nov 24, 2014 at 8:01 PM, Ian Duffy i...@ianduffy.ie wrote: +0 (Don't want to get in the way...) Tested with my standard automated virtualised cloudstack environment. Failed to import a template successfully. The template downloaded, it hung on installing template for awhile eventually got an error of Failed post download script: timeout The logs repeat the following over and over: INFO [c.c.a.m.AgentManagerImpl] (AgentMonitor-1:ctx-0209bee9) Found the following agents behind on ping: [1] INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-12:ctx-c5084767) Investigating why host 1 has disconnected with event PingTimeout INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-12:ctx-c5084767) The state determined is Up INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-12:ctx-c5084767) Agent is determined to be up and running WARN [c.c.a.m.DirectAgentAttache] (DirectAgentCronJob-15:ctx-b3fbf6da) Unable to get current status on 1(localhost.localdomain) I don't appear to have any network issues with the hypervisor from the management server. The system vms booted up just fine and look healthy. The API params for configuring xenserver advanced networking tags are still different thus breaking marvin. -- Daan
[GitHub] cloudstack pull request: Add improved support for packaging CloudS...
GitHub user spark404 opened a pull request: https://github.com/apache/cloudstack/pull/46 Add improved support for packaging CloudStack for CentOS 7 This feature splits the packaging for CentOS 6 and CentOS 7 again. With the introduction of tomcat7 and systemd to much changes to keep it in the same spec. Move the package command to a higher level directory and added an option to specify for which platform to build (-d centos7|centos63). Tested by creating a management server using the RPMs and configuring cloudstack to run with Xenserver (6.4.99). This pretty much checks startup and the ability to do database upgrades and find hypervisor scripts. You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/cloudstack feature/centos7-rpm Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/46.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #46 commit 870ede5a04e5b832a13e6750e942215c81c4ee6c Author: Hugo Trippaers htrippa...@schubergphilis.com Date: 2014-11-20T15:50:50Z Add improved support for packaging CloudStack for CentOS 7 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[DISCUSS] LTS Releases
Hi, During CCCEU14 conference and over emails, I spoke with many CloudStack users and I think most of us would like to have and use LTS releases. I propose that; - We encourage a habit to backport a bugfix to all qualifying branches whether or not those branches are LTS - We contribute (unit, integration) tests on LTS branches as well on other qualifying branches - We put correct affect version and fix version on JIRA so issues that should be backported to a branch are identified - We adapt the LTS release model from Fedora/Ubuntu projects. Please share ideas, comments? - We officially recognize a LTS release branch, say 4.3 now and everyone helps to maintain it, backport bugfixes etc. - Until a next latest stable release is published that we all mutually agree, we keep working on the LTS branch. After say we have a stable 4.5.0 or 4.5.1 release, we can agree to recognize 4.5 as our next LTS branch and work on it. Having a robust product release means we all (developers, users, sysadmins, ops etc.) can save time consumed on firefighting a CloudStack cloud. Having a LTS branch and releases will get us there because on a LTS release/support branch we don’t do feature work at all and we only invest time to do bugfixing etc. ShapeBlue is already serving their customers with product patching service and using our own packages hosting (http://shapeblue.com/packages) we publish patches on the “main” repository for everyone. We also publish details of the patch we publish on our Github wiki, such as this example; https://github.com/shapeblue/cloudstack/wiki/Release-Notes:-ACS-4.4.1-ShapeBlue-Patch01 We’ve recently started putting patches and release notes publicly (rather than just using emails) so you’ll see more of these in future. When we make patches we push the changes to upstream branches as well, in fact we fix on upstream first. In our experience the 4.3.x releases are most stable and so we’re backporting bugfixes from 4.4/4.5/master. I’m personally going through a list of JIRA issues which has affect version 4.3.0 and/or 4.3.1 but the bugfix either does not exist or exists in a non-4.3 branch. 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.
[GitHub] cloudstack pull request: Add improved support for packaging CloudS...
Github user bhaisaab commented on the pull request: https://github.com/apache/cloudstack/pull/46#issuecomment-64387309 Looks good, but I see most of the scripts in the new centos7 packaging is the same including systemd init scripts, why not use ifs and elses? I'm interested because now ShapeBlue hosts the packages repository and with this change we'll have to maintain 4 different rpm repos. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Review Request 28049: CLOUDSTACK-7917: Load Balancer Rule is not validated when updating LB
On Nov. 25, 2014, 8:14 a.m., Rajani Karuturi wrote: Ship It! Rajani Karuturi wrote: Thanks for adding tests. pushed to 4.5 c919ff83d81528b89017b5f5731b2e46350e3dfa will merge to master as well. Rajani Karuturi wrote: master 02ca6f2e5b7d8ffdc917ed09d8600c38e668ea17 Thanks Rajani - Daniel --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28049/#review62950 --- On Nov. 24, 2014, 4:23 p.m., Daniel Vega Simoes wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28049/ --- (Updated Nov. 24, 2014, 4:23 p.m.) Review request for cloudstack. Repository: cloudstack-git Description --- JIRA: https://issues.apache.org/jira/browse/CLOUDSTACK-7917 Validate Load Balancer rule with provider before commiting to DB and applying new rule. Diffs - server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java a28d108 server/test/com/cloud/network/lb/UpdateLoadBalancerTest.java PRE-CREATION Diff: https://reviews.apache.org/r/28049/diff/ Testing --- Created 2 new unit tests that are located in server/test/com/cloud/network/lb/UpdateLoadBalancerTest.java - Test to guarantee that validate is being called when updating LB rule - Test to guarantee that it throws exception if LB rule is not validated by provider Ran integration tests (smoke), all seems OK. Thanks, Daniel Vega Simoes
Jenkins build is back to stable : simulator-singlerun #693
See http://jenkins.buildacloud.org/job/simulator-singlerun/693/changes
[GitHub] cloudstack commit comment: 870ede5a04e5b832a13e6750e942215c81c4ee6...
Github user wilderrodrigues commented on commit 870ede5a04e5b832a13e6750e942215c81c4ee6c: https://github.com/apache/cloudstack/commit/870ede5a04e5b832a13e6750e942215c81c4ee6c#commitcomment-8715056 In packaging/centos7/replace.properties: In packaging/centos7/replace.properties on line 52: Shouldn't it be python 2.7 with centos7? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)
On Tue, Nov 25, 2014 at 1:06 PM, Ian Duffy i...@ianduffy.ie wrote: OK Thanks Ian, Pulling every thing you said out of context; I take this as a 0++. I will be working on the release later today. -- Daan
Re: [DISCUSS] LTS Releases
Hi, On 11/25/2014 12:30 PM, Rohit Yadav wrote: Hi, During CCCEU14 conference and over emails, I spoke with many CloudStack users and I think most of us would like to have and use LTS releases. I propose that; - We encourage a habit to backport a bugfix to all qualifying branches whether or not those branches are LTS - We contribute (unit, integration) tests on LTS branches as well on other qualifying branches - We put correct affect version and fix version on JIRA so issues that should be backported to a branch are identified - We adapt the LTS release model from Fedora/Ubuntu projects. Please share ideas, comments? - We officially recognize a LTS release branch, say 4.3 now and everyone helps to maintain it, backport bugfixes etc. - Until a next latest stable release is published that we all mutually agree, we keep working on the LTS branch. After say we have a stable 4.5.0 or 4.5.1 release, we can agree to recognize 4.5 as our next LTS branch and work on it. Having a robust product release means we all (developers, users, sysadmins, ops etc.) can save time consumed on firefighting a CloudStack cloud. Having a LTS branch and releases will get us there because on a LTS release/support branch we don’t do feature work at all and we only invest time to do bugfixing etc. ShapeBlue is already serving their customers with product patching service and using our own packages hosting (http://shapeblue.com/packages) we publish patches on the “main” repository for everyone. We also publish details of the patch we publish on our Github wiki, such as this example; https://github.com/shapeblue/cloudstack/wiki/Release-Notes:-ACS-4.4.1-ShapeBlue-Patch01 We’ve recently started putting patches and release notes publicly (rather than just using emails) so you’ll see more of these in future. When we make patches we push the changes to upstream branches as well, in fact we fix on upstream first. In our experience the 4.3.x releases are most stable and so we’re backporting bugfixes from 4.4/4.5/master. I’m personally going through a list of JIRA issues which has affect version 4.3.0 and/or 4.3.1 but the bugfix either does not exist or exists in a non-4.3 branch. I'm not against it at all, I think that a lot of end-users would really want this. But aren't we a bit to soon? I agree that 4.3 is a good version which is out there and 4.4.2 seems to be as well, but where do we make the decision? I think that we should have master more stable before we can do this. Backporting things from master to 4.3 is already a time consuming job due to the big differences between the branches. At PCextreme we run on 4.3 with our own homebrew version where we got some patches from master to 4.3, but that is already taking a lot of time. Wido 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: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)
Repeated the whole process again, looks to be going OK this time round. On 25 November 2014 at 10:21, Ian Duffy i...@ianduffy.ie wrote: Hi Daan, It was the importing of a standard template added via the UI. I will re-try again today to ensure it wasn't a networking fault (unlikely) but the messages about the host disconnecting randomly does have me concerned. I was using the system vm template from jenkins. http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-systemvm64/lastSuccessfulBuild/artifact/tools/appliance/dist/systemvm64template-4.4-2014-11-24-xen.vhd.bz2 On 25 November 2014 at 10:11, Daan Hoogland daan.hoogl...@gmail.com wrote: Thanks Lucian, I am not sure what Ians failing scenario is? It might be the download process that is failing and it might be the starting. On Tue, Nov 25, 2014 at 11:05 AM, Nux! n...@li.nux.ro wrote: I'll upgrade my test setup (4.4.1) today and get back to you. Do I need a new systemvm or can I just leave the old one from 4.4.1 in place? -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Daan Hoogland daan.hoogl...@gmail.com To: dev dev@cloudstack.apache.org, Ian Duffy i...@ianduffy.ie Sent: Tuesday, 25 November, 2014 09:37:36 Subject: Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2) Anybody else seeing this? @Ian, please confirm this is a regression compared to 4.4.1. Ans can you describe the scenario/is this a regular template test or a systemvm template? I will not regard this a blocker without confirmation. We have enough +1 binding but I will extend voting a bit. Daan On Mon, Nov 24, 2014 at 8:01 PM, Ian Duffy i...@ianduffy.ie wrote: +0 (Don't want to get in the way...) Tested with my standard automated virtualised cloudstack environment. Failed to import a template successfully. The template downloaded, it hung on installing template for awhile eventually got an error of Failed post download script: timeout The logs repeat the following over and over: INFO [c.c.a.m.AgentManagerImpl] (AgentMonitor-1:ctx-0209bee9) Found the following agents behind on ping: [1] INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-12:ctx-c5084767) Investigating why host 1 has disconnected with event PingTimeout INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-12:ctx-c5084767) The state determined is Up INFO [c.c.a.m.AgentManagerImpl] (AgentTaskPool-12:ctx-c5084767) Agent is determined to be up and running WARN [c.c.a.m.DirectAgentAttache] (DirectAgentCronJob-15:ctx-b3fbf6da) Unable to get current status on 1(localhost.localdomain) I don't appear to have any network issues with the hypervisor from the management server. The system vms booted up just fine and look healthy. The API params for configuring xenserver advanced networking tags are still different thus breaking marvin. -- Daan
Re: Review Request 28390: CLOUDSTACK-7965: Fix script related to force delete domain test case
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28390/#review62971 --- Ship it! 2805f51e433d4005469c656ed03854a83028637b 4.5 4f825288290cc7ec67301a3aa1306d30eb1e682b master - SrikanteswaraRao Talluri On Nov. 24, 2014, 10:58 a.m., Ashutosh Kelkar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28390/ --- (Updated Nov. 24, 2014, 10:58 a.m.) Review request for cloudstack, sanjeev n and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-7965 https://issues.apache.org/jira/browse/CLOUDSTACK-7965 Repository: cloudstack-git Description --- Fixing a test script issue. When forceful domain deletion fails, code in except adds the child accounts in cleanup list. But they might have deleted during the domain deletion operation. In that case the cleanup operation fails. Domain deletion should be outside the try catch block. Diffs - test/integration/component/test_persistent_networks.py f782700 Diff: https://reviews.apache.org/r/28390/diff/ Testing --- Yes. Thanks, Ashutosh Kelkar
Re: Review Request 28327: CLOUDSTACK-7938: Marvin - Create a new section in test_data.py for configurable data and change test cases accordingly
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28327/#review62974 --- Ship it! d7940cca1e731ad92f566d16ef040afbc407932a 4.5 684268f4c3a6be1441f1f47df2979185c91bfcaf master - SrikanteswaraRao Talluri On Nov. 24, 2014, 6:21 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28327/ --- (Updated Nov. 24, 2014, 6:21 a.m.) Review request for cloudstack, sanjeev n and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-7938 https://issues.apache.org/jira/browse/CLOUDSTACK-7938 Repository: cloudstack-git Description --- Separating the configurable data from test_data.py and putting it in different section so that we know which data needs changes according to the setup and environment. Made according changes in test cases. Removed the static data from the test cases. Removed method from common.py which is used no more. Diffs - test/integration/component/test_lb_secondary_ip.py 841257f test/integration/component/test_netscaler_configs.py 91fb85b test/integration/component/test_netscaler_lb.py e3d65bb test/integration/component/test_netscaler_lb_algo.py 0d571b4 test/integration/component/test_netscaler_lb_sticky.py a5f55a8 test/integration/component/test_persistent_networks.py f782700 test/integration/component/test_portable_ip.py cf0cb3b test/integration/smoke/test_primary_storage.py 310afca tools/marvin/marvin/config/test_data.py 2f97d5f tools/marvin/marvin/lib/common.py 63662b9 Diff: https://reviews.apache.org/r/28327/diff/ Testing --- Yes. All test suites tested and changes working fine. Thanks, Gaurav Aradhye
Re: Review Request 28389: CLOUDSTACK-7963: Fixed test case in test_dedicate_guest_vlan_ranges.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28389/#review62976 --- Ship it! 825cae8d927218c987d2426417e1be354fb0f29d 4.5 1db2d144229f5e69331c49b7b8922750984b78be master - SrikanteswaraRao Talluri On Nov. 24, 2014, 6:12 a.m., Ashutosh Kelkar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28389/ --- (Updated Nov. 24, 2014, 6:12 a.m.) Review request for cloudstack, sanjeev n and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-7963 https://issues.apache.org/jira/browse/CLOUDSTACK-7963 Repository: cloudstack-git Description --- Test case failed with exception: int() argument must be a string or a number, not 'NoneType' It fails while checking if the vlan id of the network is from the dedicated range. The network does not get vlan id in the first place because it is not in implemented state. Solution: Either deploy a VM in the network or implement the network with persistent network offering Changes: Used persistent network offering instead of normal offering. Diffs - test/integration/component/test_dedicate_guest_vlan_ranges.py efba229 Diff: https://reviews.apache.org/r/28389/diff/ Testing --- Release a dedicated vlan range when no vlan id is in use ... === TestName: test_05_release_range_vlan_in_use | Status : SUCCESS === ok -- Ran 1 test in 61.409s OK Thanks, Ashutosh Kelkar
Re: Review Request 28281: CLOUDSTACK-7953: Fixed time wait period for verifying snapshot policy
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28281/#review62978 --- Ship it! 0ce9439d371d8240add34da48f48533c9ef4cba6 4.5 50ab04dc0d73c0192c0693d62c047cfaffc73e99 master - SrikanteswaraRao Talluri On Nov. 20, 2014, 11:17 a.m., Ashutosh Kelkar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28281/ --- (Updated Nov. 20, 2014, 11:17 a.m.) Review request for cloudstack, sanjeev n and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-7953 https://issues.apache.org/jira/browse/CLOUDSTACK-7953 Repository: cloudstack-git Description --- The wait period for checking the max snapshots created by snapshot policy should be double the snapshot policy time. In that way we can be sure that snapshot policy is not creating snapshots more than maxsnaps parameter. Diffs - test/integration/component/test_snapshot_limits.py 18a1c65 Diff: https://reviews.apache.org/r/28281/diff/ Testing --- Yes. Thanks, Ashutosh Kelkar
Re: Review Request 28278: CLOUDSTACK-7949: Fixing issue in test_base_image_updation.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28278/#review62980 --- Ship it! c25b6fab122118bd9a0e4e14d103ac015e52ab5a 4.5 6eb4a40afe743e4a200730073e084a4d11026219 master - SrikanteswaraRao Talluri On Nov. 20, 2014, 10:59 a.m., Ashutosh Kelkar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28278/ --- (Updated Nov. 20, 2014, 10:59 a.m.) Review request for cloudstack, sanjeev n and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-7949 https://issues.apache.org/jira/browse/CLOUDSTACK-7949 Repository: cloudstack-git Description --- The test case test_04 failed while rebooting because the template it was using was being deleted in test_03. Instead the template should be deleted after all the test cases have executed. Made according changes and also fixeed the assertion. Diffs - test/integration/component/test_base_image_updation.py 8288f2c Diff: https://reviews.apache.org/r/28278/diff/ Testing --- Test deploy an instance with service offerings with IsVolatile set. ... === TestName: test_01_deploy_instance_with_is_volatile_offering | Status : SUCCESS === ok Test rebooting instances created with isVolatile service offerings ... === TestName: test_02_reboot_instance_with_is_volatile_offering | Status : SUCCESS === ok Test restoring a vm with different template than the one it was created with ... === TestName: test_03_restore_vm_with_new_template | Status : SUCCESS === ok 1) Create a VM using the Service offering IsVolatile enabled ... === TestName: test_04_reoccuring_snapshot_rules | Status : SUCCESS === ok -- Ran 4 tests in 5416.231s OK Thanks, Ashutosh Kelkar
Re: [DISCUSS] LTS Releases
Like Wido, I also agree with LTS, but also think 4.3 is kind of old by now and 4.4.2 is looking good. Perhaps take a step back and see how 4.5 goes and start with that one? -- 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 Cc: us...@cloudstack.apache.org Sent: Tuesday, 25 November, 2014 11:30:53 Subject: [DISCUSS] LTS Releases Hi, During CCCEU14 conference and over emails, I spoke with many CloudStack users and I think most of us would like to have and use LTS releases. I propose that; - We encourage a habit to backport a bugfix to all qualifying branches whether or not those branches are LTS - We contribute (unit, integration) tests on LTS branches as well on other qualifying branches - We put correct affect version and fix version on JIRA so issues that should be backported to a branch are identified - We adapt the LTS release model from Fedora/Ubuntu projects. Please share ideas, comments? - We officially recognize a LTS release branch, say 4.3 now and everyone helps to maintain it, backport bugfixes etc. - Until a next latest stable release is published that we all mutually agree, we keep working on the LTS branch. After say we have a stable 4.5.0 or 4.5.1 release, we can agree to recognize 4.5 as our next LTS branch and work on it. Having a robust product release means we all (developers, users, sysadmins, ops etc.) can save time consumed on firefighting a CloudStack cloud. Having a LTS branch and releases will get us there because on a LTS release/support branch we don’t do feature work at all and we only invest time to do bugfixing etc. ShapeBlue is already serving their customers with product patching service and using our own packages hosting (http://shapeblue.com/packages) we publish patches on the “main” repository for everyone. We also publish details of the patch we publish on our Github wiki, such as this example; https://github.com/shapeblue/cloudstack/wiki/Release-Notes:-ACS-4.4.1-ShapeBlue-Patch01 We’ve recently started putting patches and release notes publicly (rather than just using emails) so you’ll see more of these in future. When we make patches we push the changes to upstream branches as well, in fact we fix on upstream first. In our experience the 4.3.x releases are most stable and so we’re backporting bugfixes from 4.4/4.5/master. I’m personally going through a list of JIRA issues which has affect version 4.3.0 and/or 4.3.1 but the bugfix either does not exist or exists in a non-4.3 branch. 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: Review Request 28225: CLOUDSTACK-7942: Fixing account permission issue in test_template.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28225/#review62982 --- Ship it! 7197f8c24a8fd661cd4fabacd564399a6e537439 4.5 30a2ade17ac3bcdfe26351d0c86f28194c381b7a master - SrikanteswaraRao Talluri On Nov. 19, 2014, noon, Ashutosh Kelkar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28225/ --- (Updated Nov. 19, 2014, noon) Review request for cloudstack, sanjeev n and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-7942 https://issues.apache.org/jira/browse/CLOUDSTACK-7942 Repository: cloudstack-git Description --- Creating virtual machine was failing because it was using the template created with the root admin account. Instead the account should create the template. Diffs - test/integration/component/test_templates.py 769848d Diff: https://reviews.apache.org/r/28225/diff/ Testing --- Create Template from snapshot ... === TestName: test_04_template_from_snapshot | Status : SUCCESS === ok -- Ran 1 test in 588.850s OK Thanks, Ashutosh Kelkar
Re: Review Request 28163: CLOUDSTACK-7934: Fixed cleanup issues test_escalations_volumes.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28163/#review62984 --- Ship it! df6078bb2d160d55c2c6b21fd3234187c8091a90 4.5 2fbef677b0edfcd705c0df6d244f7327e8ea938c master - SrikanteswaraRao Talluri On Nov. 18, 2014, 9:47 a.m., Ashutosh Kelkar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28163/ --- (Updated Nov. 18, 2014, 9:47 a.m.) Review request for cloudstack, sanjeev n and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-7934 https://issues.apache.org/jira/browse/CLOUDSTACK-7934 Repository: cloudstack-git Description --- Snapshots, volumes get cleaned up after each test case as part of account cleanup. No need to add them separately to cleanup list. Diffs - test/integration/component/test_escalations_volumes.py 7290325 Diff: https://reviews.apache.org/r/28163/diff/ Testing --- Yes. Log: @summary: Test List Volumes pagination ... SKIP: Skip @summary: Test List Volumes with Id ... SKIP: Skip @summary: Test to verify creation and resize of data volume ... SKIP: Skip @summary: Test to verify creation and resize of custom volume ... SKIP: Skip @summary: Test to verify creation of snapshot from volume ... SKIP: Skip @summary: Test to verify creation of Hourly Snapshot policies ... SKIP: Skip @summary: Test to verify creation of Daily Snapshot policies ... SKIP: Skip @summary: Test to verify creation of Weekly Snapshot policies ... SKIP: Skip @summary: Test to verify creation of Monthly Snapshot policies ... SKIP: Skip @summary: Test to verify pagination of snapshots for Volume ... SKIP: Skip @summary: Test to verify extract/download a Volume ... SKIP: Skip @summary: Test to verify upload volume ... SKIP: Skip @Desc:Create volume from custom disk offering does not work as expected ... === TestName: test_13_volume_custom_disk_size | Status : SUCCESS === ok -- Ran 13 tests in 170.553s OK (SKIP=12) @summary: Test List Volumes pagination ... SKIP: Skip @summary: Test List Volumes with Id ... SKIP: Skip @summary: Test to verify creation and resize of data volume ... SKIP: Skip @summary: Test to verify creation and resize of custom volume ... SKIP: Skip @summary: Test to verify creation of snapshot from volume ... === TestName: test_05_volume_snapshot | Status : SUCCESS === ok @summary: Test to verify creation of Hourly Snapshot policies ... SKIP: Skip @summary: Test to verify creation of Daily Snapshot policies ... SKIP: Skip @summary: Test to verify creation of Weekly Snapshot policies ... SKIP: Skip @summary: Test to verify creation of Monthly Snapshot policies ... SKIP: Skip @summary: Test to verify pagination of snapshots for Volume ... === TestName: test_10_volume_snapshots_pagination | Status : SUCCESS === ok Thanks, Ashutosh Kelkar
Re: Review Request 28161: CLOUDSTACK-7933: test_escalations_instances.py - Fixed test_13_vm_nics for Vmware
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28161/#review62986 --- Ship it! 1bc13f753773a31ea4ca0ce90975147bca17142d 4.5 d0ca2d5d8b1575bf8c7d1b6566cea15c8a2264bb master - SrikanteswaraRao Talluri On Nov. 18, 2014, 6:25 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28161/ --- (Updated Nov. 18, 2014, 6:25 a.m.) Review request for cloudstack and SrikanteswaraRao Talluri. Bugs: CLOUDSTACK-7933 https://issues.apache.org/jira/browse/CLOUDSTACK-7933 Repository: cloudstack-git Description --- Skipping remove nic operation for VMware when vmware tools are not installed on VM. Diffs - test/integration/component/test_escalations_instances.py fd25bb9 Diff: https://reviews.apache.org/r/28161/diff/ Testing --- Yes. log: @Desc: Test to verify Nics for a VM ... === TestName: test_13_vm_nics | Status : SUCCESS === ok -- Ran 1 test in 255.060s OK Thanks, Gaurav Aradhye
Re: [DISCUSS] LTS Releases
Hi Wido and Lucian, There are many ways to get to a stable product including fixing coverity issues, unit/integration tests etc. but one of those ways is to simply support existing releases with bugfix releases because most CloudStack users just don’t care about git workflows, or coverity or unit/integration tests, they simply expect it to work and if it has bugs they expect them to be fixed. We don’t have production usage data and feedback from users to conclude that 4.4.x releases are stable enough. Some of them (include our customers) have tried to upgrade their test prod. environments from 4.3.x to 4.4.x and have failed. So we decided to put backporting/testing efforts on 4.3 which we have confidence that it just works until a stable 4.5.x on which we have a certain confidence is released. Just to put out a note here - many smart and active contributors/users may know their way around CloudStack such as Wido/PCExtreme and Lucian, but many large/serious CloudStack users are slow to change and upgrading every 3-4 months may not be an option for them. I know quite a few users who are operating large clouds and are still on ACS 4.2.x. This simply means they are not going to simply upgrade just because there is a new release with lots of new features. Therefore the idea of supporting those releases until we have a confidence of a new stable release. Note: This is not to say that 4.4.x is not stable, we’re simply saying we recommend 4.3.x because we have a confidence of its stability and we encourage serious CloudStack users to use it. The 4.4 branch does not contain many bugfixes which are in 4.3 and on master/4.5. I anticipate that 4.5.0 should be out in about 2 months time around Jan/Feb 2015. With this anticipation and known confidence of 4.3.x in production at ShapeBlue we decided to support 4.3 branch until a stable 4.5.x branch is out. On 25-Nov-2014, at 6:39 pm, Nux! n...@li.nux.ro wrote: Like Wido, I also agree with LTS, but also think 4.3 is kind of old by now and 4.4.2 is looking good. Perhaps take a step back and see how 4.5 goes and start with that one? -- 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 Cc: us...@cloudstack.apache.org Sent: Tuesday, 25 November, 2014 11:30:53 Subject: [DISCUSS] LTS Releases Hi, During CCCEU14 conference and over emails, I spoke with many CloudStack users and I think most of us would like to have and use LTS releases. I propose that; - We encourage a habit to backport a bugfix to all qualifying branches whether or not those branches are LTS - We contribute (unit, integration) tests on LTS branches as well on other qualifying branches - We put correct affect version and fix version on JIRA so issues that should be backported to a branch are identified - We adapt the LTS release model from Fedora/Ubuntu projects. Please share ideas, comments? - We officially recognize a LTS release branch, say 4.3 now and everyone helps to maintain it, backport bugfixes etc. - Until a next latest stable release is published that we all mutually agree, we keep working on the LTS branch. After say we have a stable 4.5.0 or 4.5.1 release, we can agree to recognize 4.5 as our next LTS branch and work on it. Having a robust product release means we all (developers, users, sysadmins, ops etc.) can save time consumed on firefighting a CloudStack cloud. Having a LTS branch and releases will get us there because on a LTS release/support branch we don’t do feature work at all and we only invest time to do bugfixing etc. ShapeBlue is already serving their customers with product patching service and using our own packages hosting (http://shapeblue.com/packages) we publish patches on the “main” repository for everyone. We also publish details of the patch we publish on our Github wiki, such as this example; https://github.com/shapeblue/cloudstack/wiki/Release-Notes:-ACS-4.4.1-ShapeBlue-Patch01 We’ve recently started putting patches and release notes publicly (rather than just using emails) so you’ll see more of these in future. When we make patches we push the changes to upstream branches as well, in fact we fix on upstream first. In our experience the 4.3.x releases are most stable and so we’re backporting bugfixes from 4.4/4.5/master. I’m personally going through a list of JIRA issues which has affect version 4.3.0 and/or 4.3.1 but the bugfix either does not exist or exists in a non-4.3 branch. 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/
Re: [DISCUSS] LTS Releases
On Tue, Nov 25, 2014 at 2:40 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: The 4.4 branch does not contain many bugfixes which are in 4.3 and on master/4.5. That is worrying, Rohit. As the rest of your mail is already a vote of distrust, this part says we should not release 4.4.2 as it contains regressions. This is a very bad signal to users and the rest of the community. What you are saying is (you in transitive form), 'we won't port fixes to 4.4 but only to 4.3 so upgrade to newer 4.3 versions and not to a 4.4 version. You have the right to do so but I don't like it. Fortunately, I met people at CCCEU stating that 4.4 was working perfectly for them. Unfortunately an incompatibility seldom is just for- or backward. Most of the time it is two way. Will you support transitioning from 4.4 to 4.5 as rigorously as you now discourage the transition to 4.4? I think you will need to. -- Daan
Build failed in Jenkins: cloudstack-4.3-maven-build-noredist #494
See http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build-noredist/494/ -- Started by upstream project cloudstack-4.3-maven-build build number 650 originally caused by: Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on cloudstack-buildslave-centos6-87d (cloudstack-buildslave-centos6) in workspace http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build-noredist/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 git://git.apache.org/cloudstack.git # timeout=400 Fetching upstream changes from git://git.apache.org/cloudstack.git /usr/bin/git --version # timeout=400 /usr/bin/git fetch --tags --progress git://git.apache.org/cloudstack.git +refs/heads/*:refs/remotes/origin/* FATAL: Failed to fetch from git://git.apache.org/cloudstack.git hudson.plugins.git.GitException: Failed to fetch from git://git.apache.org/cloudstack.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:647) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:889) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:914) at hudson.model.AbstractProject.checkout(AbstractProject.java:1258) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528) at hudson.model.Run.execute(Run.java:1759) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) Caused by: hudson.plugins.git.GitException: Command /usr/bin/git fetch --tags --progress git://git.apache.org/cloudstack.git +refs/heads/*:refs/remotes/origin/* returned status code 128: stdout: stderr: remote: Counting objects: 1 remote: Counting objects: 18 remote: Counting objects: 23 remote: Counting objects: 28 remote: Counting objects: 31 remote: Counting objects: 33 remote: Counting objects: 34 remote: Counting objects: 35 remote: Counting objects: 36 remote: Counting objects: 38 remote: Counting objects: 39 remote: Counting objects: 44 remote: Counting objects: 46 remote: Counting objects: 93 remote: Counting objects: 98 remote: Counting objects: 104 remote: Counting objects: 106 remote: Counting objects: 108 remote: Counting objects: 111 remote: Counting objects: 113 remote: Counting objects: 114 remote: Counting objects: 116 remote: Counting objects: 118 remote: Counting objects: 119 remote: Counting objects: 123 remote: Counting objects: 128 remote: Counting objects: 138 remote: Counting objects: 140 remote: Counting objects: 144 remote: Counting objects: 147 remote: Counting objects: 148 remote: Counting objects: 153 remote: Counting objects: 178 remote: Counting objects: 180 remote: Counting objects: 186 remote: Counting objects: 194 remote: Counting objects: 199 remote: Counting objects: 202 remote: Counting objects: 204 remote: Counting objects: 206 remote: Counting objects: 210 remote: Counting objects: 214 remote: Counting objects: 225 remote: Counting objects: 228 remote: Counting objects: 230 remote: Counting objects: 231 remote: Counting objects: 235 remote: Counting objects: 237 remote: Counting objects: 238 remote: Counting objects: 243 remote: Counting objects: 244 remote: Counting objects: 246 remote: Counting objects: 249 remote: Counting objects: 253 remote: Counting objects: 261 remote: Counting objects: 262 remote: Counting objects: 269 remote: Counting objects: 280 remote: Counting objects: 338 remote: Counting objects: 345 remote: Counting objects: 372 remote: Counting objects: 384 remote: Counting objects: 393 remote: Counting objects: 410 remote: Counting objects: 433 remote: Counting objects: 440 remote: Counting objects: 444 remote: Counting objects: 446 remote: Counting objects: 449 remote: Counting objects: 451 remote: Counting objects: 475 remote: Counting objects: 478 remote:
Re: [DISCUSS] LTS Releases
Rohit, Agreed, I know very well how it is to get stuck with a certain version and your (and everyone's) need for backports. Your decision re 4.3 seems to make sense, it looks in good (blue?) shape. 4.5 is starting to look very interesting. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Rohit Yadav rohit.ya...@shapeblue.com To: us...@cloudstack.apache.org Cc: dev@cloudstack.apache.org Sent: Tuesday, 25 November, 2014 13:40:23 Subject: Re: [DISCUSS] LTS Releases Hi Wido and Lucian, There are many ways to get to a stable product including fixing coverity issues, unit/integration tests etc. but one of those ways is to simply support existing releases with bugfix releases because most CloudStack users just don’t care about git workflows, or coverity or unit/integration tests, they simply expect it to work and if it has bugs they expect them to be fixed. We don’t have production usage data and feedback from users to conclude that 4.4.x releases are stable enough. Some of them (include our customers) have tried to upgrade their test prod. environments from 4.3.x to 4.4.x and have failed. So we decided to put backporting/testing efforts on 4.3 which we have confidence that it just works until a stable 4.5.x on which we have a certain confidence is released. Just to put out a note here - many smart and active contributors/users may know their way around CloudStack such as Wido/PCExtreme and Lucian, but many large/serious CloudStack users are slow to change and upgrading every 3-4 months may not be an option for them. I know quite a few users who are operating large clouds and are still on ACS 4.2.x. This simply means they are not going to simply upgrade just because there is a new release with lots of new features. Therefore the idea of supporting those releases until we have a confidence of a new stable release. Note: This is not to say that 4.4.x is not stable, we’re simply saying we recommend 4.3.x because we have a confidence of its stability and we encourage serious CloudStack users to use it. The 4.4 branch does not contain many bugfixes which are in 4.3 and on master/4.5. I anticipate that 4.5.0 should be out in about 2 months time around Jan/Feb 2015. With this anticipation and known confidence of 4.3.x in production at ShapeBlue we decided to support 4.3 branch until a stable 4.5.x branch is out.
Re: [DISCUSS] LTS Releases
Daan, I like 4.4 better than 4.3 for my use case and despite the bugs I hit it does its job. If I were to deploy today it would still be with 4.4. Hope this makes you feel better. :-) Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Daan Hoogland daan.hoogl...@gmail.com To: dev dev@cloudstack.apache.org Cc: us...@cloudstack.apache.org Sent: Tuesday, 25 November, 2014 13:56:12 Subject: Re: [DISCUSS] LTS Releases On Tue, Nov 25, 2014 at 2:40 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: The 4.4 branch does not contain many bugfixes which are in 4.3 and on master/4.5. That is worrying, Rohit. As the rest of your mail is already a vote of distrust, this part says we should not release 4.4.2 as it contains regressions. This is a very bad signal to users and the rest of the community. What you are saying is (you in transitive form), 'we won't port fixes to 4.4 but only to 4.3 so upgrade to newer 4.3 versions and not to a 4.4 version. You have the right to do so but I don't like it. Fortunately, I met people at CCCEU stating that 4.4 was working perfectly for them. Unfortunately an incompatibility seldom is just for- or backward. Most of the time it is two way. Will you support transitioning from 4.4 to 4.5 as rigorously as you now discourage the transition to 4.4? I think you will need to. -- Daan
RE: [DISCUSS] LTS Releases
I do prefer 4.4 as well because it has GPU sharing and we actively test it. Other bugs are not so important for us right now. Vadim. -Original Message- From: Nux! [mailto:n...@li.nux.ro] Sent: Tuesday, November 25, 2014 4:48 PM To: dev@cloudstack.apache.org Cc: us...@cloudstack.apache.org Subject: Re: [DISCUSS] LTS Releases Daan, I like 4.4 better than 4.3 for my use case and despite the bugs I hit it does its job. If I were to deploy today it would still be with 4.4. Hope this makes you feel better. :-) Lucian -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - From: Daan Hoogland daan.hoogl...@gmail.com To: dev dev@cloudstack.apache.org Cc: us...@cloudstack.apache.org Sent: Tuesday, 25 November, 2014 13:56:12 Subject: Re: [DISCUSS] LTS Releases On Tue, Nov 25, 2014 at 2:40 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: The 4.4 branch does not contain many bugfixes which are in 4.3 and on master/4.5. That is worrying, Rohit. As the rest of your mail is already a vote of distrust, this part says we should not release 4.4.2 as it contains regressions. This is a very bad signal to users and the rest of the community. What you are saying is (you in transitive form), 'we won't port fixes to 4.4 but only to 4.3 so upgrade to newer 4.3 versions and not to a 4.4 version. You have the right to do so but I don't like it. Fortunately, I met people at CCCEU stating that 4.4 was working perfectly for them. Unfortunately an incompatibility seldom is just for- or backward. Most of the time it is two way. Will you support transitioning from 4.4 to 4.5 as rigorously as you now discourage the transition to 4.4? I think you will need to. -- Daan
Re: [DISCUSS] LTS Releases
On Tue, Nov 25, 2014 at 3:47 PM, Nux! n...@li.nux.ro wrote: I like 4.4 better than 4.3 for my use case and despite the bugs I hit it does its job. If I were to deploy today it would still be with 4.4. Hope this makes you feel better. :-) It makes me feel the hero;) Seriously, I don't feel bad about 4.4, but I am worried of a legacy of 4.3 being created were 4.4 effectively becomes a fork of the product while 4.3 keeps converging back to 4.5. Rohit is putting tremendous effort into 4.3 that I will certainly not put into 4.4. I don't mind doing some convergence work. This is not our use case. I don't want to compete with Rohit. I raise the subject because of my concerns for the project. -- Daan
Re: [DISCUSS] LTS Releases
Hey Daan, On 25-Nov-2014, at 7:26 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: That is worrying, Rohit. As the rest of your mail is already a vote of distrust, this part says we should not release 4.4.2 as it contains regressions. Looks like you skimmed my email and missed the following from my previous email: “Note: This is not to say that 4.4.x is not stable, we’re simply saying we recommend 4.3.x because we have a confidence of its stability and we encourage serious CloudStack users to use it.” 4.4.x is probably the greatest ACS feature release ever but I would still recommend conservative users (who consult me) to stick to 4.3.x for production since we know it just works with least amount of pain. The other issue is I know a lot of people who are on ACS 4.3.x still (including ShapeBlue’s customers) want to have bugfix releases and they may not want to migrate to 4.4.x right now since 4.5.x is about 2–3 months away. ACS when consumed by enterprise companies has a typical lifecycle that lasts at least 6 months, that means someone needs to support it, therefore the idea of official LTS releases. This is a very bad signal to users and the rest of the community. What you are saying is (you in transitive form), 'we won't port fixes to 4.4 but only to 4.3 so upgrade to newer 4.3 versions and not to a 4.4 version. You have the right to do so but I don't like it. In any form I did not say anything about not helping out or not porting things. People who know me, know that I love to help everyone and I’m quite prompt at reply and resolving things. I’ve taken the task to maintain 4.3 and you’re very welcome to go thorough JIRA etc. to backport things that you want for 4.4 since you’re alone the gatekeeper of this branch. I’m going through these bugs that have a different fix version (not 4.3.0 or 4.3.1): https://issues.apache.org/jira/issues/?filter=12329775 Wido suggested that backporting is time consuming so as a challenge I’ve went through 50 issues today, I was able to understand/backport about 25 of them that qualified for 4.3 branch (many of them were trivial, https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=f72eb945540e607ff25917922b4084187246f31a), about 10 of them were hard to backport so I’ve asked authors to help out. I think with this speed I alone should be able to go through like 300 issues reported on JIRA in about 10-15 days time and after than about 10-20 days of testing and getting the bugfix release out. Though if we all help out we can get more mileage. It sucks for me personally that I’ve been emailing you privately about cherry-pick and asking you to pick them on 4.4 (also leaving messages on JIRA). I’ll continue to do that :) and meanwhile, you are very welcome to go see the things I picked on 4.3 and pick those applicable on 4.4. Yours friendly and as always, 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.
Jenkins build became unstable: simulator-singlerun #695
See http://jenkins.buildacloud.org/job/simulator-singlerun/695/changes
Re: Review Request 28437: CLOUDSTACK-6282 Added automated ACL tests
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28437/#review62993 --- test/integration/component/test_escalations_networks.py https://reviews.apache.org/r/28437/#comment105166 We have simple assert available through self.assert, can we use that, to keep uniform notation across all other places? test/integration/component/test_escalations_networks.py https://reviews.apache.org/r/28437/#comment105164 Description does not seem to represent test case name test/integration/component/test_escalations_networks.py https://reviews.apache.org/r/28437/#comment105163 Is aclgroup None a failure or not None a failure? test/integration/component/test_escalations_networks.py https://reviews.apache.org/r/28437/#comment105165 why not simple len(aclList) instead of aclList.__len__()? test/integration/component/test_escalations_networks.py https://reviews.apache.org/r/28437/#comment105162 There are no steps for this test case test/integration/component/test_escalations_networks.py https://reviews.apache.org/r/28437/#comment105157 This is not clear, is it that we are expecting it to be None and if not None fail the test case? test/integration/component/test_escalations_networks.py https://reviews.apache.org/r/28437/#comment105160 Please provide a valid name instead of network_created to some meaningful. test/integration/component/test_escalations_networks.py https://reviews.apache.org/r/28437/#comment105161 This network creation is not available in steps for the test test/integration/component/test_escalations_networks.py https://reviews.apache.org/r/28437/#comment105158 try adding the element vpc right after creation. If test case fails for some reason between vpc creation and network creation step, then say vpc created still remain as it is and will effect other steps. test/integration/component/test_escalations_networks.py https://reviews.apache.org/r/28437/#comment105159 Why two asserts for same element network_created - Santhosh Edukulla On Nov. 25, 2014, 10:24 a.m., anusha bilgi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28437/ --- (Updated Nov. 25, 2014, 10:24 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 ACL tests Diffs - test/integration/component/test_escalations_networks.py fb2196c Diff: https://reviews.apache.org/r/28437/diff/ Testing --- Tests the changed files and attached are the results for the same File Attachments results.txt https://reviews.apache.org/media/uploaded/files/2014/11/25/61351189-70e9-4fa6-8bcf-035d28fa61e6__results.txt Thanks, anusha bilgi
Re: [DISCUSS] LTS Releases
Rohit, I consider you my friend and colleague, I could reply on everything said but do not want to escalate on all the details. The only remark I want to make is that 4.4 is open for commits from here on in. On Tue, Nov 25, 2014 at 4:16 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hey Daan, On 25-Nov-2014, at 7:26 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: -- Daan
Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)
+1 for: http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-package-rpm/ -- build 317 http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-systemvm64/ -- build 171 Regards Tom 2014-11-21 3:59 GMT+01:00 Daan Hoogland daan.hoogl...@gmail.com: Hi All, I've created a 4.4.2 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4 Commit: e0420a6fec738d728bc59ba65bc5e12809bde0eb List of changes: `CLOUDSTACK-7887 https://issues.apache.org/jira/browse/CLOUDSTACK-7887`_ fail to push snapshot to secondary storage if using multipart using swift... `CLOUDSTACK-7883 https://issues.apache.org/jira/browse/CLOUDSTACK-7883`_ Allow infrastructure to handle delete of volume from DB... `CLOUDSTACK-7871 https://issues.apache.org/jira/browse/CLOUDSTACK-7871`_ Fix update VirtualMachine/Template API to allow nic/disk controller details for ... `CLOUDSTACK-7855 https://issues.apache.org/jira/browse/CLOUDSTACK-7855`_ Sec storage/network MTU should be on nic3 and not nic1... `CLOUDSTACK-7826 https://issues.apache.org/jira/browse/CLOUDSTACK-7826`_ UI - dialog widget - dependent dropdown field (dependsOn property specified) - f... `CLOUDSTACK-7822 https://issues.apache.org/jira/browse/CLOUDSTACK-7822`_ test SSL cert expired... `CLOUDSTACK-7752 https://issues.apache.org/jira/browse/CLOUDSTACK-7752`_ Management Server goes in infinite loop while creating a vm with tagged local da... `CLOUDSTACK-7722 https://issues.apache.org/jira/browse/CLOUDSTACK-7722`_ add.label: Add button for tags show the label not Add text... `CLOUDSTACK-7246 https://issues.apache.org/jira/browse/CLOUDSTACK-7246`_ VM deployment failed due to wrong in script name createipalias.sh... Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.4.2 PGP release keys (signed using 4096R/AA4736F3): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Vote will be open for 72 hours. For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Daan -- Regards, Tomasz Zięba Twitter: @TZieba LinkedIn: pl.linkedin.com/pub/tomasz-zięba-ph-d/3b/7a8/ab6/ http://pl.linkedin.com/pub/tomasz-zi%C4%99ba-ph-d/3b/7a8/ab6/
Re: [DISCUSS] LTS Releases
Top posting here as my remarks are mainly on the original topic. I’m not in favor of supporting LTS releases as a community. The reasoning here is that there is a huge chance that we will fragment the community in people that just want to work on the latest and greatest and some other folks who are trying to keep older releases from being updated with newer fixes. It requires a lot of dedicated commitment to keep an LTS release going. Particularly if you yourself are already working with a newer release in your environment. So from a personal standpoint i can almost guarantee that i will probably not spend the time and effort of back porting any fixes i do to older versions of CloudStack. That doesn’t mean that it can’t happen. If people are willing to take charge of an LTS branch and are willing to do the work to back port fixes where appropriate i would happily support them and even try to test the releases so we can have an official release. New developers might also be scared by the fact that a fix they make has to be supported on multiple branches and might decide not to commit such a fix because of the work involved. With the rate of change in the code at the moment this is also very hard for seasoned developers, so much little, but important stuff changes all the time that back porting is very difficult. It is an open source project and generally people will want to focus on the latest and greatest and just get their features in. I’m already regularly having some trouble back porting between master and 4.5. Consider back porting to master, 4.5 and 4.3 as well and having to test each branch. Basically my point is, everyone who wants to LTS support a certain branch is free to do so. Whether or not other contributors or committers will want to do that is their choice. As a community we should not make any promises about LTS support for a certain branch. Cheers, Hugo On 25 nov. 2014, at 16:16, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hey Daan, On 25-Nov-2014, at 7:26 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: That is worrying, Rohit. As the rest of your mail is already a vote of distrust, this part says we should not release 4.4.2 as it contains regressions. Looks like you skimmed my email and missed the following from my previous email: “Note: This is not to say that 4.4.x is not stable, we’re simply saying we recommend 4.3.x because we have a confidence of its stability and we encourage serious CloudStack users to use it.” 4.4.x is probably the greatest ACS feature release ever but I would still recommend conservative users (who consult me) to stick to 4.3.x for production since we know it just works with least amount of pain. The other issue is I know a lot of people who are on ACS 4.3.x still (including ShapeBlue’s customers) want to have bugfix releases and they may not want to migrate to 4.4.x right now since 4.5.x is about 2–3 months away. ACS when consumed by enterprise companies has a typical lifecycle that lasts at least 6 months, that means someone needs to support it, therefore the idea of official LTS releases. This is a very bad signal to users and the rest of the community. What you are saying is (you in transitive form), 'we won't port fixes to 4.4 but only to 4.3 so upgrade to newer 4.3 versions and not to a 4.4 version. You have the right to do so but I don't like it. In any form I did not say anything about not helping out or not porting things. People who know me, know that I love to help everyone and I’m quite prompt at reply and resolving things. I’ve taken the task to maintain 4.3 and you’re very welcome to go thorough JIRA etc. to backport things that you want for 4.4 since you’re alone the gatekeeper of this branch. I’m going through these bugs that have a different fix version (not 4.3.0 or 4.3.1): https://issues.apache.org/jira/issues/?filter=12329775 Wido suggested that backporting is time consuming so as a challenge I’ve went through 50 issues today, I was able to understand/backport about 25 of them that qualified for 4.3 branch (many of them were trivial, https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=f72eb945540e607ff25917922b4084187246f31a), about 10 of them were hard to backport so I’ve asked authors to help out. I think with this speed I alone should be able to go through like 300 issues reported on JIRA in about 10-15 days time and after than about 10-20 days of testing and getting the bugfix release out. Though if we all help out we can get more mileage. It sucks for me personally that I’ve been emailing you privately about cherry-pick and asking you to pick them on 4.4 (also leaving messages on JIRA). I’ll continue to do that :) and meanwhile, you are very welcome to go see the things I picked on 4.3 and pick those applicable on 4.4. Yours friendly and as always, Rohit Yadav Software Architect, ShapeBlue
[GitHub] cloudstack pull request: Add improved support for packaging CloudS...
Github user spark404 commented on the pull request: https://github.com/apache/cloudstack/pull/46#issuecomment-64430200 @bhaisaab some of the files still need to be replaced, like the init scripts for the other services. They are copied for now and will be replaced by cents 7 counter parts later. Most of the other files have had changes and a lot of files were actually removed or replaced by files without parameters (as most of the files were generated using replace.properties). I actually started working with the if and else, but it turned out there is too many of them to keep the logic readable for others. Also note that in the spec file a lot of the upgrade code has been removed. As this will be the first packages made for CentOS 7 so we don't need a lot of the scripting to upgrade from really old versions of cloudstack to a new version (packaging wise, upgrade inside cloudstack is a different matter) All in all i hope that you'll find the centos7 packaging a lot cleaner when compared to the centos63 one. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
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/#review62996 --- test/integration/component/test_escalations_ipaddresses.py https://reviews.apache.org/r/27611/#comment105167 We dont need this check, validateList already has taken care of this. test/integration/component/test_escalations_ipaddresses.py https://reviews.apache.org/r/27611/#comment105171 Why list again, may be we want to list once and verify the required cases all once post the list? test/integration/component/test_escalations_ipaddresses.py https://reviews.apache.org/r/27611/#comment105172 We dont need this length validation again test/integration/component/test_escalations_ipaddresses.py https://reviews.apache.org/r/27611/#comment105170 Too much of repetetive code here i believe, why not list all publicipaddress and then check for required conditions? May be it will reduce the number of lines here. test/integration/component/test_escalations_ipaddresses.py https://reviews.apache.org/r/27611/#comment105174 Is clean up required for self.account? test/integration/component/test_escalations_isos.py https://reviews.apache.org/r/27611/#comment105175 Is the comment right? test/integration/component/test_escalations_networks.py https://reviews.apache.org/r/27611/#comment105176 This is not required. test/integration/component/test_escalations_volumes.py https://reviews.apache.org/r/27611/#comment105179 Why do we need to assert here? test/integration/component/test_escalations_vpncustomergateways.py https://reviews.apache.org/r/27611/#comment105177 We dont need this i believe test/integration/component/test_escalations_vpncustomergateways.py https://reviews.apache.org/r/27611/#comment105178 I believe the message sould be not matching by name - Santhosh Edukulla On Nov. 5, 2014, 10:40 a.m., Avinash Gautam wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27611/ --- (Updated Nov. 5, 2014, 10:40 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 41e5b2f test/integration/component/test_escalations_isos.py 4e818a5 test/integration/component/test_escalations_networks.py fb2196c test/integration/component/test_escalations_securitygroups.py ffaf657 test/integration/component/test_escalations_snapshots.py 4b6b7f5 test/integration/component/test_escalations_templates.py 3dc24c1 test/integration/component/test_escalations_volumes.py 7290325 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
Jenkins build is still unstable: simulator-singlerun #696
See http://jenkins.buildacloud.org/job/simulator-singlerun/changes
Re: [DISCUSS] LTS Releases
- Original Message - Hi, During CCCEU14 conference and over emails, I spoke with many CloudStack users and I think most of us would like to have and use LTS releases. I propose that; - We encourage a habit to backport a bugfix to all qualifying branches whether or not those branches are LTS - We contribute (unit, integration) tests on LTS branches as well on other qualifying branches - We put correct affect version and fix version on JIRA so issues that should be backported to a branch are identified - We adapt the LTS release model from Fedora/Ubuntu projects. Please share ideas, comments? - We officially recognize a LTS release branch, say 4.3 now and everyone helps to maintain it, backport bugfixes etc. - Until a next latest stable release is published that we all mutually agree, we keep working on the LTS branch. After say we have a stable 4.5.0 or 4.5.1 release, we can agree to recognize 4.5 as our next LTS branch and work on it. Having a robust product release means we all (developers, users, sysadmins, ops etc.) can save time consumed on firefighting a CloudStack cloud. Having a LTS branch and releases will get us there because on a LTS release/support branch we don’t do feature work at all and we only invest time to do bugfixing etc. +1 with everything. It is essential for the end users to have a bug fix releases instead of waiting for the next release to come. I've noticed that with CloudStack project majority of latest releases have been delayed from their initial estimated dates. This creates a lot of false expectations and false hopes for the end users who are waiting for the bug fixes. I guess a lot of productions users would rather see a bug being fixed than get a bunch of new features, which are likely to be broken or unpolished in the first release. Also, new releases are likely to introduce additional issues upon upgrading forcing people to downgrade back to their old releases with old unfixed bugs. The LTS release would solve a lot of issues and frustrations and should actually be beneficial to the project and community. In my opinion the Ubuntu team has captured the releases cycles perfectly well. Perhaps ACS should have a stable release every 2 years and a testing release every 2 or 4 quarters. This way, the users will be happy to have a solid backported platform that they can run in production and the developers will be happy working on a new feature set. ShapeBlue is already serving their customers with product patching service and using our own packages hosting (http://shapeblue.com/packages) we publish patches on the “main” repository for everyone. We also publish details of the patch we publish on our Github wiki, such as this example; https://github.com/shapeblue/cloudstack/wiki/Release-Notes:-ACS-4.4.1-ShapeBlue-Patch01 We’ve recently started putting patches and release notes publicly (rather than just using emails) so you’ll see more of these in future. When we make patches we push the changes to upstream branches as well, in fact we fix on upstream first. Kudos to ShapeBlue team!!! Many thanks for your contributions and help on promoting this project. I love you guys!!! In our experience the 4.3.x releases are most stable and so we’re backporting bugfixes from 4.4/4.5/master. I’m personally going through a list of JIRA issues which has affect version 4.3.0 and/or 4.3.1 but the bugfix either does not exist or exists in a non-4.3 branch. 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
Re: CloudStack Simulator on Google Compute VM
I did this on AWS, works like a charm. Sent from my iPhone On 25 Nov 2014, at 1:19 pm, Madan Ganesh Velayudham madangan...@me.com wrote: Hello, Has anyone tried to bring up simulator on any of the public cloud platforms (AWS, Google Compute or others). We’re trying to install cloudstack simulator on Google Compute VM. Appreciate your pointers. Cheers, Madan
Build failed in Jenkins: cloudstack-4.3-maven-build #651
See http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build/651/ -- [...truncated 6235 lines...] remote: Compressing objects: 46% (49996/107975) remote: Compressing objects: 46% (50109/107975) remote: Compressing objects: 46% (50121/107975) remote: Compressing objects: 46% (50123/107975) remote: Compressing objects: 46% (50130/107975) remote: Compressing objects: 47% (50749/107975) remote: Compressing objects: 47% (50970/107975) remote: Compressing objects: 47% (50978/107975) remote: Compressing objects: 47% (50979/107975) remote: Compressing objects: 47% (50980/107975) remote: Compressing objects: 47% (50996/107975) remote: Compressing objects: 47% (51000/107975) remote: Compressing objects: 47% (51004/107975) remote: Compressing objects: 47% (51007/107975) remote: Compressing objects: 47% (51134/107975) remote: Compressing objects: 47% (51139/107975) remote: Compressing objects: 47% (51386/107975) remote: Compressing objects: 47% (51539/107975) remote: Compressing objects: 47% (51545/107975) remote: Compressing objects: 47% (51559/107975) remote: Compressing objects: 47% (51561/107975) remote: Compressing objects: 47% (51564/107975) remote: Compressing objects: 47% (51631/107975) remote: Compressing objects: 47% (51634/107975) remote: Compressing objects: 47% (51635/107975) remote: Compressing objects: 47% (51768/107975) remote: Compressing objects: 47% (51769/107975) remote: Compressing objects: 47% (51776/107975) remote: Compressing objects: 47% (51777/107975) remote: Compressing objects: 47% (51778/107975) remote: Compressing objects: 47% (51779/107975) remote: Compressing objects: 47% (51782/107975) remote: Compressing objects: 47% (51784/107975) remote: Compressing objects: 47% (51786/107975) remote: Compressing objects: 47% (51787/107975) remote: Compressing objects: 47% (51802/107975) remote: Compressing objects: 47% (51806/107975) remote: Compressing objects: 47% (51810/107975) remote: Compressing objects: 47% (51812/107975) remote: Compressing objects: 47% (51813/107975) remote: Compressing objects: 47% (51816/107975) remote: Compressing objects: 47% (51820/107975) remote: Compressing objects: 48% (51828/107975) remote: Compressing objects: 48% (51829/107975) remote: Compressing objects: 48% (51834/107975) remote: Compressing objects: 48% (51835/107975) remote: Compressing objects: 48% (51836/107975) remote: Compressing objects: 48% (51844/107975) remote: Compressing objects: 48% (51845/107975) remote: Compressing objects: 48% (51846/107975) remote: Compressing objects: 48% (51850/107975) remote: Compressing objects: 48% (51913/107975) remote: Compressing objects: 48% (51915/107975) remote: Compressing objects: 48% (51916/107975) remote: Compressing objects: 48% (51917/107975) remote: Compressing objects: 48% (51925/107975) remote: Compressing objects: 48% (51932/107975) remote: Compressing objects: 48% (52061/107975) remote: Compressing objects: 48% (52313/107975) remote: Compressing objects: 48% (52314/107975) remote: Compressing objects: 48% (52315/107975) remote: Compressing objects: 48% (52318/107975) remote: Compressing objects: 48% (52319/107975) remote: Compressing objects: 48% (52362/107975) remote: Compressing objects: 48% (52394/107975) remote: Compressing objects: 48% (52398/107975) remote: Compressing objects: 48% (52399/107975) remote: Compressing objects: 48% (52403/107975) remote: Compressing objects: 48% (52431/107975) remote: Compressing objects: 48% (52432/107975) remote: Compressing objects: 48% (52433/107975) remote: Compressing objects: 48% (52435/107975) remote: Compressing objects: 48% (52465/107975) remote: Compressing objects: 48% (52466/107975) remote: Compressing objects: 48% (52470/107975) remote: Compressing objects: 48% (52471/107975) remote: Compressing objects: 48% (52477/107975) remote: Compressing objects: 48% (52479/107975) remote: Compressing objects: 48% (52481/107975) remote: Compressing objects: 48% (52483/107975) remote: Compressing objects: 48% (52597/107975)
Build failed in Jenkins: cloudstack-4.3-maven-build #652
See http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build/652/ -- Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on cloudstack-buildslave-centos6-a99 (cloudstack-buildslave-centos6) in workspace http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build/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 git://git.apache.org/cloudstack.git # timeout=400 Fetching upstream changes from git://git.apache.org/cloudstack.git /usr/bin/git --version # timeout=400 /usr/bin/git fetch --tags --progress git://git.apache.org/cloudstack.git +refs/heads/*:refs/remotes/origin/* FATAL: Failed to fetch from git://git.apache.org/cloudstack.git hudson.plugins.git.GitException: Failed to fetch from git://git.apache.org/cloudstack.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:647) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:889) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:914) at hudson.model.AbstractProject.checkout(AbstractProject.java:1258) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528) at hudson.model.Run.execute(Run.java:1759) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) Caused by: hudson.plugins.git.GitException: Command /usr/bin/git fetch --tags --progress git://git.apache.org/cloudstack.git +refs/heads/*:refs/remotes/origin/* returned status code 128: stdout: stderr: remote: Counting objects: 13 remote: Counting objects: 17 remote: Counting objects: 42 remote: Counting objects: 55 remote: Counting objects: 57 remote: Counting objects: 61 remote: Counting objects: 64 remote: Counting objects: 79 remote: Counting objects: 87 remote: Counting objects: 88 remote: Counting objects: 111 remote: Counting objects: 123 remote: Counting objects: 126 remote: Counting objects: 128 remote: Counting objects: 131 remote: Counting objects: 135 remote: Counting objects: 138 remote: Counting objects: 141 remote: Counting objects: 143 remote: Counting objects: 156 remote: Counting objects: 157 remote: Counting objects: 162 remote: Counting objects: 165 remote: Counting objects: 166 remote: Counting objects: 167 remote: Counting objects: 170 remote: Counting objects: 173 remote: Counting objects: 174 remote: Counting objects: 176 remote: Counting objects: 177 remote: Counting objects: 178 remote: Counting objects: 179 remote: Counting objects: 180 remote: Counting objects: 181 remote: Counting objects: 182 remote: Counting objects: 183 remote: Counting objects: 184 remote: Counting objects: 185 remote: Counting objects: 186 remote: Counting objects: 193 remote: Counting objects: 202 remote: Counting objects: 207 remote: Counting objects: 208 remote: Counting objects: 209 remote: Counting objects: 211 remote: Counting objects: 216 remote: Counting objects: 220 remote: Counting objects: 221 remote: Counting objects: 224 remote: Counting objects: 228 remote: Counting objects: 233 remote: Counting objects: 238 remote: Counting objects: 241 remote: Counting objects: 244 remote: Counting objects: 249 remote: Counting objects: 258 remote: Counting objects: 261 remote: Counting objects: 264 remote: Counting objects: 269 remote: Counting objects: 276 remote: Counting objects: 280 remote: Counting objects: 286 remote: Counting objects: 294 remote: Counting objects: 297 remote: Counting
Build failed in Jenkins: cloudstack-4.3-maven-build #653
See http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build/653/ -- Started by an SCM change [EnvInject] - Loading node environment variables. Building remotely on cloudstack-buildslave-centos6-a99 (cloudstack-buildslave-centos6) in workspace http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build/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 git://git.apache.org/cloudstack.git # timeout=400 Fetching upstream changes from git://git.apache.org/cloudstack.git /usr/bin/git --version # timeout=400 /usr/bin/git fetch --tags --progress git://git.apache.org/cloudstack.git +refs/heads/*:refs/remotes/origin/* FATAL: Failed to fetch from git://git.apache.org/cloudstack.git hudson.plugins.git.GitException: Failed to fetch from git://git.apache.org/cloudstack.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:647) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:889) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:914) at hudson.model.AbstractProject.checkout(AbstractProject.java:1258) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528) at hudson.model.Run.execute(Run.java:1759) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) Caused by: hudson.plugins.git.GitException: Command /usr/bin/git fetch --tags --progress git://git.apache.org/cloudstack.git +refs/heads/*:refs/remotes/origin/* returned status code 128: stdout: stderr: remote: Counting objects: 17 remote: Counting objects: 42 remote: Counting objects: 57 remote: Counting objects: 73 remote: Counting objects: 88 remote: Counting objects: 132 remote: Counting objects: 136 remote: Counting objects: 138 remote: Counting objects: 140 remote: Counting objects: 141 remote: Counting objects: 142 remote: Counting objects: 143 remote: Counting objects: 158 remote: Counting objects: 159 remote: Counting objects: 171 remote: Counting objects: 185 remote: Counting objects: 227 remote: Counting objects: 242 remote: Counting objects: 246 remote: Counting objects: 255 remote: Counting objects: 271 remote: Counting objects: 287 remote: Counting objects: 318 remote: Counting objects: 325 remote: Counting objects: 326 remote: Counting objects: 349 remote: Counting objects: 356 remote: Counting objects: 365 remote: Counting objects: 390 remote: Counting objects: 399 remote: Counting objects: 408 remote: Counting objects: 411 remote: Counting objects: 419 remote: Counting objects: 439 remote: Counting objects: 453 remote: Counting objects: 467 remote: Counting objects: 475 remote: Counting objects: 513 remote: Counting objects: 536 remote: Counting objects: 542 remote: Counting objects: 548 remote: Counting objects: 554 remote: Counting objects: 589 remote: Counting objects: 599 remote: Counting objects: 614 remote: Counting objects: 630 remote: Counting objects: 655 remote: Counting objects: 696 remote: Counting objects: 708 remote: Counting objects: 737 remote: Counting objects: 13179 remote: Counting objects: 38886 remote: Counting objects: 44089 remote: Counting objects: 44281 remote: Counting objects: 45519 remote: Counting objects: 46504 remote: Counting objects: 47481 remote: Counting objects: 48935 remote: Counting objects: 52522 remote: Counting objects: 54331 remote: Counting objects: 54364 remote: Counting objects: 54427 remote: Counting objects: 54430 remote: Counting objects: 54433 remote: Counting objects: 54476 remote: Counting objects: 54478 remote: Counting objects: 54628 remote: Counting objects: 54722 remote: Counting objects: 54845 remote: Counting objects: 54872 remote: Counting objects: 55390 remote: Counting objects: 55747 remote: Counting objects: 55771 remote: Counting
Jenkins build is back to normal : cloudstack-4.3-maven-build #654
See http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build/654/changes
Jenkins build is back to normal : cloudstack-4.3-maven-build-noredist #495
See http://jenkins.buildacloud.org/job/cloudstack-4.3-maven-build-noredist/495/changes
Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount
Instead of adding yet another parameter, could we look into adding a generic filter as in: http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-DescribeInstances.html From: Rohit Yadav rohit.ya...@shapeblue.commailto:rohit.ya...@shapeblue.com Reply-To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Date: Tuesday, November 25, 2014 at 1:27 AM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Good ideas, I’ll use them. So I think no one disagrees with this; - list VMs still has user_id, but deployVM won’t - We’ll use first user in the account if someone’s impersonating; else use logged in user to get user_id On 25-Nov-2014, at 12:17 am, Prachi Damle prachi.da...@citrix.commailto:prachi.da...@citrix.com wrote: Hi Rohit, I see your point: when deploy VM is called by an admin impersonating another account, the user_id value will be set to logged in user, which will be the admin. And this will break your usecase. Correct? Do you think your functionality needs this usecase i.e an admin impersonating deployVm for another user? If you won't hit this scenario primarily, we can just set the user_id to first user in the account being impersonated to cover this case - just as your upgrade code for existing Vms. What do you think? Thanks, Prachi -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: Friday, November 21, 2014 11:13 PM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount Hi Min, Prachi, Thanks for your comments. I see your point, the use case is to list VMs for a user_id (uuid, not name). I'm going to add the arg/option the listVM api to accept user_id and return the list of VMs for that user, and add option in the UI to do the same. Note, this is not for auditing purposes (for that we have events). But, since we allow impersonation of account while deploying a VM by the same logic we should allow impersonation at the user_id as well which we only accept in the deploy VM API if an account/domain is mentioned along with the user_id. If I only use logged-in user ID, it makes implementation very simple but at the same time but sort of breaks impersonation semantics. Note: the fix will be simple, won't change IAM and this is just to add capability to list VMs for a user ID. On 21-Nov-2014, at 11:57 pm, Prachi Damle prachi.da...@citrix.commailto:prachi.da...@citrix.com wrote: Hi Rohit, The accountId in deployVm API is serving the purpose of impersonation and can be passed typically by admin accounts to deploy VM on behalf of other User. So Ideally with IAM, this parameter should be removed from the API and impersonation should be handled separately. Keeping this goal, I think let's not add userID parameter in the API. We should default the value to the logged in user - this will prevent usecases around cross-account/cross-user scenarios. Thanks, Prachi -Original Message- From: Min Chen [mailto:min.c...@citrix.com] Sent: Friday, November 21, 2014 8:16 AM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: [DISCUSS] Major business logic refactoring: Move from Account to UserAccount If I understood correctly, (account, domainId) passed into deployVMCmd is used for impersonation-like behavior, that is, caller is deploying a VM on behalf of an account. Personally I don't like this kind of putting so many parameters in one API to perform several different functionalities, impersonation should be done through IAM separately. Too many parameters will just make our API semantics very hard to understand and maintain. Along this line, I will not like to see this user_id added here. Thanks -min On 11/21/14 5:20 AM, Rohit Yadav rohit.ya...@shapeblue.commailto:rohit.ya...@shapeblue.com wrote: Hi Prachi, Since we¹re already allowing users to specific account and list VMs by account, following the same pattern I added the case so as to allow users to specify user_id in both list/deploy VM commands. In case the userid is not specified, in that case the logged in user¹s ID will be used. It¹s open for discussion of course, let me know if it¹s a good idea to follow the same pattern or strictly use the logged-in user¹s ID? On 21-Nov-2014, at 1:41 am, Prachi Damle prachi.da...@citrix.commailto:prachi.da...@citrix.com wrote: Rohit, I checked the code here https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog; h= ref s/heads/useraccount-refactoring and I don't understand why we need to expose the userId parameter in the deployVm API. I think we should be using the userId of the logged in user always. Exposing the parameter at the API allows it to be set by
Re: Moving ec2stack and gstack to the cloudstack repos.
I think unit tests are great for type checking and the like, but are there any integration tests? If there is a change made to the CloudStack API (usually a parameter is added to the response, rarely a semantic change), will some automated test find the breakage if any? Any plans to add any? From: Ian Duffy i...@ianduffy.iemailto:i...@ianduffy.ie Reply-To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Date: Monday, November 24, 2014 at 2:43 PM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: Moving ec2stack and gstack to the cloudstack repos. Chiradeep, Of course, check out the git repository at https://github.com/brogand1993/ec2stack the code is pretty clean and there is 99% test coverage. TravisCI is setup to run on every commit and execute the tests along with pylint for static analysis. There's a screencast here of a rough overview https://www.youtube.com/watch?v=xvu-gc8h4Qglist=UUoGs2iiOIGrfXofp-3g-Qqg It looks at installation, configuration and basic usage against exoscale using awscli. Regards, Ian On 24 Nov 2014 19:02, Chiradeep Vittal chiradeep.vit...@citrix.commailto:chiradeep.vit...@citrix.com wrote: Good to know, but are there any automated tests? From: Ian Duffy i...@ianduffy.iemailto:i...@ianduffy.iemailto:i...@ianduffy.ie Reply-To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Date: Monday, November 24, 2014 at 10:56 AM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: Moving ec2stack and gstack to the cloudstack repos. Chiradeep, During the development of ec2stack we tested it using boto, awscli, vagrant-aws and eutester. Hope this satisfy your concerns. On 24 November 2014 at 18:19, Chiradeep Vittal chiradeep.vit...@citrix.commailto:chiradeep.vit...@citrix.commailto:chiradeep.vit...@citrix.com wrote: Seems legit, but from (bitter) experience, there is no point in a compatible API layer unless somebody puts in the elbow grease to test the compatibility. Since the actual EC2 API as implemented by AWS changes frequently and has undocumented semantics and behavior that varies from the WSDL, this takes some work. So, my question would be how would this benefit the community (unless someone has tested out the compatibility with various tools such as boto, ec2-* CLI). From: Sebastien Goasguen run...@gmail.commailto:run...@gmail.commailto:run...@gmail.com mailto:run...@gmail.com Reply-To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org mailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Date: Saturday, November 22, 2014 at 12:41 PM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Moving ec2stack and gstack to the cloudstack repos. Folks, Some of you may know of the existence of: https://github.com/BroganD1993/ec2stack https://github.com/NOPping/gstack These represent a EC2 and a GCE interface to cloudstack. Flask applications that map the requests to the cloudstack API. There was only 3 contributors, myself, Ian (PMC and committer on CS) and Darren Brogan. Darren worked on this during his GSoC 2014 summer project. Both projects are on Apache V2 license. The three of us (Ian, Darren and myself) agree that we would like to move them under the umbrella of cloudstack and manage separate releases like we do cloud monkey. Any objections ? -Sebastien
Re: [ACS44]release 4.4.2 release candidate RC20141121T0341 (#2)
Does 4.4.2 require new set of systemvm compare to 4.4.1 ? On Tue, Nov 25, 2014 at 11:15 AM, Tomasz Zięba t.a.zi...@gmail.com wrote: +1 for: http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-package-rpm/ -- build 317 http://jenkins.buildacloud.org/view/4.4/job/cloudstack-4.4-systemvm64/ -- build 171 Regards Tom 2014-11-21 3:59 GMT+01:00 Daan Hoogland daan.hoogl...@gmail.com: Hi All, I've created a 4.4.2 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4 Commit: e0420a6fec738d728bc59ba65bc5e12809bde0eb List of changes: `CLOUDSTACK-7887 https://issues.apache.org/jira/browse/CLOUDSTACK-7887`_ fail to push snapshot to secondary storage if using multipart using swift... `CLOUDSTACK-7883 https://issues.apache.org/jira/browse/CLOUDSTACK-7883`_ Allow infrastructure to handle delete of volume from DB... `CLOUDSTACK-7871 https://issues.apache.org/jira/browse/CLOUDSTACK-7871`_ Fix update VirtualMachine/Template API to allow nic/disk controller details for ... `CLOUDSTACK-7855 https://issues.apache.org/jira/browse/CLOUDSTACK-7855`_ Sec storage/network MTU should be on nic3 and not nic1... `CLOUDSTACK-7826 https://issues.apache.org/jira/browse/CLOUDSTACK-7826`_ UI - dialog widget - dependent dropdown field (dependsOn property specified) - f... `CLOUDSTACK-7822 https://issues.apache.org/jira/browse/CLOUDSTACK-7822`_ test SSL cert expired... `CLOUDSTACK-7752 https://issues.apache.org/jira/browse/CLOUDSTACK-7752`_ Management Server goes in infinite loop while creating a vm with tagged local da... `CLOUDSTACK-7722 https://issues.apache.org/jira/browse/CLOUDSTACK-7722`_ add.label: Add button for tags show the label not Add text... `CLOUDSTACK-7246 https://issues.apache.org/jira/browse/CLOUDSTACK-7246`_ VM deployment failed due to wrong in script name createipalias.sh... Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.4.2 PGP release keys (signed using 4096R/AA4736F3): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Vote will be open for 72 hours. For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Daan -- Regards, Tomasz Zięba Twitter: @TZieba LinkedIn: pl.linkedin.com/pub/tomasz-zięba-ph-d/3b/7a8/ab6/ http://pl.linkedin.com/pub/tomasz-zi%C4%99ba-ph-d/3b/7a8/ab6/ http://pl.linkedin.com/pub/tomasz-zi%C4%99ba-ph-d/3b/7a8/ab6/
Re: Moving ec2stack and gstack to the cloudstack repos.
hi all, I need help for a clean picture about the umbrella projects of cloudstack: such as : 1. the umbrella project links in cloudstack.org homepage 2. the source code structure and relations with cloudstack source code in git repos. 3. the rules for us to agree one as umbrella projects BTW, is there any others umbrella proejcts as cloudmonkey ? -- Regards, ChunFeng -- Original -- From: Sebastien Goasguenrun...@gmail.com; Date: Tue, Nov 25, 2014 06:29 AM To: devdev@cloudstack.apache.org; Subject: Re: Moving ec2stack and gstack to the cloudstack repos. On Nov 24, 2014, at 5:05 PM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I do see a bug fix this year from Likitha and the fact that Hugo etc are making fixes is positive as well. But, the end state we desire is (a) good AWSAPI implementation with automated tests, not (b) 2 AWSAPI implementations with no tests! time for bed here, but to keep the conversation going, couple things: Hugo is fixing coverity issues kind of automatically, I don't think it represents a need. One fix from Likitha and one applied patch from me in a year is really slim. We don't test the current awsapi during the release process or upgrade, so I actually have no clue if it's working with 4.3 and 4.4. Right now I don't see tests for the current awsapi, at least not on jenkins.buildacloud.org. Current awsapi also includes S3 stuff which I think we can all agree is confusing and unused since it's really an interface to an NFS store and not a distributed object store. So the choice for me is between: -current awsapi, not clearly maintained, without tests and which state in the release is unknown and -a new implementation 6 months old, smaller code base, up to date with AWS version number, tested manually with boto, eutester and awscli and with 99% unit test coverage. — Chiradeep From: Sebastien Goasguen run...@gmail.commailto:run...@gmail.com Reply-To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Date: Monday, November 24, 2014 at 1:36 PM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: Moving ec2stack and gstack to the cloudstack repos. On Nov 24, 2014, at 3:44 PM, Chiradeep Vittal chiradeep.vit...@citrix.commailto:chiradeep.vit...@citrix.com wrote: “..nobody in the community (aside from you, Likitha and Prachi) have actually touched that code in the last two years. So if we don't maintain that code.. That’s false equivalence. Clearly it has been maintained since there are bug fixes. I don't know…I look at: https://github.com/apache/cloudstack/tree/master/awsapi I see Hugo has fixed some coverity issues I applied a review 8 months ago the rest is older. but maybe I am not looking at this the right way. there is one review still pending: https://reviews.apache.org/r/21776/ So from looking at it this way it does not look actively maintained. No ? But we’re looking to make things better. I am not sure HOW bringing in another compatibility layer brings benefits, UNLESS WE propose to commit time to provide a suite of integration tests (say, via eutester) Do we have a suite of integration tests for awsapi that is running right now ? where ? I did play with eutester and actually patched it to work with cloudstack when I worked on ec2stack: http://sebgoa.blogspot.de/2014/06/eutester-interesting-tool-based-on-boto.html -sebastien Thanks — Chiradeep From: sebgoa run...@gmail.commailto:run...@gmail.commailto:run...@gmail.com Reply-To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Date: Monday, November 24, 2014 at 11:39 AM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: Re: Moving ec2stack and gstack to the cloudstack repos. On Nov 24, 2014, at 7:19 PM, Chiradeep Vittal chiradeep.vit...@citrix.commailto:chiradeep.vit...@citrix.commailto:chiradeep.vit...@citrix.com wrote: Seems legit, but from (bitter) experience, there is no point in a compatible API layer unless somebody puts in the elbow grease to test the compatibility. Since the actual EC2 API as implemented by AWS changes frequently and has undocumented semantics and behavior that varies from the WSDL, this takes some work. So, my question would be how would this benefit the community (unless someone has tested out the compatibility with various tools such as boto, ec2-* CLI). I think the main issue is the on-going maintenance of such an interface. That's also one of the main
Re: [DISCUSS] Any issues to be fixed for 4.3.1?
I added 4.3.2 fixversion in jira and also moved unresolved tickets from 4.1.*, 4.2.*, 4.3.0 and 4.3.1 to 4.3.2 jira filter: https://issues.apache.org/jira/issues/?jql=project%20%3D%20CLOUDSTACK%20AND%20fixVersion%20%3D%204.3.2%20AND%20resolution%20%3D%20Unresolved%20 ~Rajani On Mon, Nov 24, 2014 at 11:56 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Thanks Mike, done. On 24-Nov-2014, at 10:15 pm, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Hi Rohit, Please go ahead and cherry pick 6602ad71ac97fb1875131f41bb5f92ff1e3a1c7b into 4.3.2. Thanks! Mike On Thu, Nov 20, 2014 at 3:14 PM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Thanks Wido, I’ve cherry-picked the fix and another fix from Will (Stevens). I’m buildling/testing it, will push on 4.3 as soon as that is done. @Mike: If your change is not changing the schema, or adding something that could break upgrade paths please go for it. If it’s already fixed, you can share the SHA with me and I can cherry-pick it and run basic build tests on it. On 20-Nov-2014, at 3:46 pm, Wido den Hollander w...@widodh.nl wrote: On 11/20/2014 10:15 AM, Rohit Yadav wrote: Hi, We’ve some bugfixes backported to 4.3 branch since 4.3.1 was released and I think we should at least support this branch with a 4.3.2 release in next couple of weeks until a stable 4.5.0 is released in next couple of months. I’m going through JIRA and list of issues and will help backport fixes to the 4.3 branch. So, please share if you’ve found any blocker/critical/major issue that you found in 4.3.0 or 4.3.1 and want to be fixed. Thanks. I think that backporting this one would be useful for users: https://issues.apache.org/jira/browse/CLOUDSTACK-3383 Simple fix, it's in master with 69ee01af9df8d72ccd8901d146726e74edda95d7 Wido 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 Build http://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment framework http://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 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. 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 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
[GitHub] cloudstack pull request: Add improved support for packaging CloudS...
Github user damodarreddy commented on the pull request: https://github.com/apache/cloudstack/pull/46#issuecomment-64516356 Already a commit is pushed to support RHEL7 build/install at 7ea7deded031b43042c68db0f7c5c6c8b21c18c2. Any problems with that commit? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
