Re: Review Request: CLOUDSTACK-1904: API : UI : Admin can not delete Events/Archive from other accounts
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10796/#review20528 --- Ship it! Ship It! - Devdeep Singh On May 13, 2013, 9:57 a.m., Sanjay Tripathi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10796/ --- (Updated May 13, 2013, 9:57 a.m.) Review request for cloudstack, Devdeep Singh, Sateesh Chodapuneedi, and Min Chen. Description --- CLOUDSTACK-1904: API : UI : Admin can not delete Events/Archive from other accounts. This addresses bug CLOUDSTACK-1904. Diffs - api/src/org/apache/cloudstack/api/command/user/event/DeleteEventsCmd.java 55ca92a engine/schema/src/com/cloud/domain/dao/DomainDao.java afeb0f4 engine/schema/src/com/cloud/domain/dao/DomainDaoImpl.java c30ca5e engine/schema/src/com/cloud/event/dao/EventDao.java da5f47a engine/schema/src/com/cloud/event/dao/EventDaoImpl.java 6ba59c5 engine/schema/src/com/cloud/user/dao/AccountDao.java 3b7fa66 engine/schema/src/com/cloud/user/dao/AccountDaoImpl.java 892fdcd server/src/com/cloud/server/ManagementServerImpl.java 86c1a64 server/test/com/cloud/event/EventControlsUnitTest.java 3c25275 Diff: https://reviews.apache.org/r/10796/diff/ Testing --- Tests: 1. Create a domain. 2. Create an admin account (a11) under this domain. 3. Login to the domain admin account and then logout (this is to generate login/logout events). 4. Login to Root Admin account. 5. Go to Events and try to delete/archive events with account=a11 (domain admin account). 6. Event got deleted and verifies the control flow of admin accounts in CloudStack. Thanks, Sanjay Tripathi
Re: Review Request: CLOUDSTACK-1904: API : UI : Admin can not delete Events/Archive from other accounts
On May 14, 2013, 6 a.m., Devdeep Singh wrote: Ship It! Can a committer pick up these changes and apply them? - Devdeep --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10796/#review20528 --- On May 13, 2013, 9:57 a.m., Sanjay Tripathi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10796/ --- (Updated May 13, 2013, 9:57 a.m.) Review request for cloudstack, Devdeep Singh, Sateesh Chodapuneedi, and Min Chen. Description --- CLOUDSTACK-1904: API : UI : Admin can not delete Events/Archive from other accounts. This addresses bug CLOUDSTACK-1904. Diffs - api/src/org/apache/cloudstack/api/command/user/event/DeleteEventsCmd.java 55ca92a engine/schema/src/com/cloud/domain/dao/DomainDao.java afeb0f4 engine/schema/src/com/cloud/domain/dao/DomainDaoImpl.java c30ca5e engine/schema/src/com/cloud/event/dao/EventDao.java da5f47a engine/schema/src/com/cloud/event/dao/EventDaoImpl.java 6ba59c5 engine/schema/src/com/cloud/user/dao/AccountDao.java 3b7fa66 engine/schema/src/com/cloud/user/dao/AccountDaoImpl.java 892fdcd server/src/com/cloud/server/ManagementServerImpl.java 86c1a64 server/test/com/cloud/event/EventControlsUnitTest.java 3c25275 Diff: https://reviews.apache.org/r/10796/diff/ Testing --- Tests: 1. Create a domain. 2. Create an admin account (a11) under this domain. 3. Login to the domain admin account and then logout (this is to generate login/logout events). 4. Login to Root Admin account. 5. Go to Events and try to delete/archive events with account=a11 (domain admin account). 6. Event got deleted and verifies the control flow of admin accounts in CloudStack. Thanks, Sanjay Tripathi
Re: Fwd: [IP CLEARANCE] CloudStack Marvin Test Suite
On Tue, May 14, 2013 at 10:29:07AM +0530, Prasanna Santhanam wrote: On Wed, May 08, 2013 at 08:00:38PM -0400, Chip Childers wrote: On Wed, May 08, 2013 at 10:43:03AM +0530, Prasanna Santhanam wrote: Thanks Chip, Indeed I've been waiting for this to finally get through legal. I'll merge it at a suitable time once the vote passes. There's going to be a some more patches coming to fix the changes we've made in the past few months to be get these tests to running state. All this work was done on github/cloudstack-qa from where the patches will be generated for reviewboard. Let's just make sure that they come in from the individuals that authored each bit of code. Merged with master (894413e362a588cc0612cfeac2b11617f4954eac). RAT check ensured. I'll have the orignal authors bring in the fixes. I made some minor syntax fixes (a92abaa) to the merged tests and posted bugs for the issues that still need resolving in the test scripts. CLOUDSTACK-2471 CLOUDSTACK-2472 CLOUDSTACK-2473 CLOUDSTACK-2474 The original authors will pick these up. Thanks, -- Prasanna., Powered by BigRock.com
Re: Review Request: CLOUDSTACK -2297 : Delete Account/Domain is not updating the resources usage of the parent domain
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11081/ --- (Updated May 14, 2013, 6:50 a.m.) Review request for cloudstack, Devdeep Singh, Sateesh Chodapuneedi, and Min Chen. Changes --- Updated patch. Description --- CLOUDSTACK-2297 : Delete Account/Domain is not updating the resources usage of the parent domain This addresses bug CLOUDSTACK-2297. Diffs (updated) - engine/schema/src/com/cloud/configuration/dao/ResourceCountDao.java 111bcb1 engine/schema/src/com/cloud/configuration/dao/ResourceCountDaoImpl.java 52bc746 engine/schema/src/com/cloud/configuration/dao/ResourceLimitDao.java 5fd79b3 engine/schema/src/com/cloud/configuration/dao/ResourceLimitDaoImpl.java d337070 server/src/com/cloud/user/AccountManagerImpl.java 4088f64 server/src/com/cloud/user/DomainManagerImpl.java dbcbe4e Diff: https://reviews.apache.org/r/11081/diff/ Testing --- Tests: 1. Create Child domains under ROOT domain 2. Create user/admin accounts under this child domain 3. Deploy one instance as the child Domain user other instance as one more account. 4. Delete the Account Verify the resources usage 5. Delete the Domain Verify the resources usage Observation: Delete Account/Domain is updating the resources usage of the parent domain Thanks, Sanjay Tripathi
Re: Review Request: CLOUDSTACK -2297 : Delete Account/Domain is not updating the resources usage of the parent domain
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11081/ --- (Updated May 14, 2013, 6:55 a.m.) Review request for cloudstack, Devdeep Singh, Sateesh Chodapuneedi, and Min Chen. Description --- CLOUDSTACK-2297 : Delete Account/Domain is not updating the resources usage of the parent domain This addresses bug CLOUDSTACK-2297. Diffs (updated) - engine/schema/src/com/cloud/configuration/dao/ResourceCountDao.java 111bcb1 engine/schema/src/com/cloud/configuration/dao/ResourceCountDaoImpl.java 52bc746 engine/schema/src/com/cloud/configuration/dao/ResourceLimitDao.java 5fd79b3 engine/schema/src/com/cloud/configuration/dao/ResourceLimitDaoImpl.java d337070 server/src/com/cloud/user/AccountManagerImpl.java 4088f64 server/src/com/cloud/user/DomainManagerImpl.java dbcbe4e Diff: https://reviews.apache.org/r/11081/diff/ Testing --- Tests: 1. Create Child domains under ROOT domain 2. Create user/admin accounts under this child domain 3. Deploy one instance as the child Domain user other instance as one more account. 4. Delete the Account Verify the resources usage 5. Delete the Domain Verify the resources usage Observation: Delete Account/Domain is updating the resources usage of the parent domain Thanks, Sanjay Tripathi
Re: Review Request: Fixed issue in configuring private gateway with sourcenatsupported=false in API
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11087/#review20530 --- Ship it! commit 55739f93b877dfcc878b1e86ed8bee64744852aa - Kishan Kavala On May 13, 2013, 3:53 p.m., Jayapal Reddy wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11087/ --- (Updated May 13, 2013, 3:53 p.m.) Review request for cloudstack, Abhinandan Prateek and Kishan Kavala. Description --- Fixed issue in configuring private gateway API with sourcenatsupported parameter false This addresses bug CLOUDSTACK-2403. Diffs - api/src/org/apache/cloudstack/api/command/admin/vpc/CreatePrivateGatewayCmd.java 6decaad Diff: https://reviews.apache.org/r/11087/diff/ Testing --- Tested by calling API with sourcenatsupported=false Thanks, Jayapal Reddy
[WIKI] Marvin Test wiki
I've rewritten most sections of the marvin wiki and organized it better now. https://cwiki.apache.org/confluence/x/QQzMAQ The earlier examples I noticed were being used to write the integration tests that the new features are including. Most of those examples were served to illustrate and not be used as is. So I've now changed the examples and also included sections for - setting up your test environment - IDE, shell, tools etc - writing the test using the libraries - debugging using the ide - running the tests from the build - extending the existing tests and some more Thanks, -- Prasanna., Powered by BigRock.com
Review Request: Deleting private gateways while deleting vpc in case multiple private gateways
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11149/ --- Review request for cloudstack, Abhinandan Prateek, Kishan Kavala, and Alena Prokharchyk. Description --- Deleting private gateways while deleting vpc in case multiple private gateways This addresses bug CLOUDSTACK-2441. Diffs - engine/schema/src/com/cloud/network/vpc/dao/VpcGatewayDao.java 8cb5c59 engine/schema/src/com/cloud/network/vpc/dao/VpcGatewayDaoImpl.java b4d403e server/src/com/cloud/network/vpc/VpcManager.java f3b4bbc server/src/com/cloud/network/vpc/VpcManagerImpl.java fb3d41e server/test/com/cloud/vpc/MockVpcManagerImpl.java 1e2cd5f Diff: https://reviews.apache.org/r/11149/diff/ Testing --- 1. Create vpc and created more than one private gateway in this vpc 2. Deleted vpc 3. observed that the all private gateways got deleted Thanks, Jayapal Reddy
[EVENTS] BACD Amsterdam
Hi, We just went live with a Build a Cloud Day event in Amsterdam on June 13th just before DevOps days. It will be at the Schuberg Phillis offices close to Schipol airport. Some great talks and a hackathon to close the day. Register at: http://bacdamsterdam.eventbrite.com or at: http://buildacloud.org/about-diy-cloud-computing/cloud-events/viewevent/170-bacd-amsterdam.html For info, DevOps days website at: http://devopsdays.org/events/2013-amsterdam/ See you all there, -Sebastien
Re: [EVENTS] BACD Amsterdam
On 05/14/2013 10:45 AM, Sebastien Goasguen wrote: Hi, We just went live with a Build a Cloud Day event in Amsterdam on June 13th just before DevOps days. It will be at the Schuberg Phillis offices close to Schipol airport. Some great talks and a hackathon to close the day. Like I already mentioned, I'm not going to make it to this one. :( Wido Register at: http://bacdamsterdam.eventbrite.com or at: http://buildacloud.org/about-diy-cloud-computing/cloud-events/viewevent/170-bacd-amsterdam.html For info, DevOps days website at: http://devopsdays.org/events/2013-amsterdam/ See you all there, -Sebastien
Re: [EVENTS] BACD Amsterdam
On May 14, 2013, at 4:50 AM, Wido den Hollander w...@widodh.nl wrote: On 05/14/2013 10:45 AM, Sebastien Goasguen wrote: Hi, We just went live with a Build a Cloud Day event in Amsterdam on June 13th just before DevOps days. It will be at the Schuberg Phillis offices close to Schipol airport. Some great talks and a hackathon to close the day. Like I already mentioned, I'm not going to make it to this one. :( Wido Your loss :) we will still have beers afterwards…actually it's at schuberg phillis so probably Cocktails :) Register at: http://bacdamsterdam.eventbrite.com or at: http://buildacloud.org/about-diy-cloud-computing/cloud-events/viewevent/170-bacd-amsterdam.html For info, DevOps days website at: http://devopsdays.org/events/2013-amsterdam/ See you all there, -Sebastien
Re: Review Request: Deleting private gateways while deleting vpc in case multiple private gateways
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11149/ --- (Updated May 14, 2013, 9:34 a.m.) Review request for cloudstack, Abhinandan Prateek, Kishan Kavala, and Alena Prokharchyk. Changes --- updated listByVpcIdAndType method Description --- Deleting private gateways while deleting vpc in case multiple private gateways This addresses bug CLOUDSTACK-2441. Diffs (updated) - engine/schema/src/com/cloud/network/vpc/dao/VpcGatewayDao.java 8cb5c59 engine/schema/src/com/cloud/network/vpc/dao/VpcGatewayDaoImpl.java b4d403e server/src/com/cloud/network/vpc/VpcManager.java f3b4bbc server/src/com/cloud/network/vpc/VpcManagerImpl.java fb3d41e server/test/com/cloud/vpc/MockVpcManagerImpl.java 1e2cd5f Diff: https://reviews.apache.org/r/11149/diff/ Testing --- 1. Create vpc and created more than one private gateway in this vpc 2. Deleted vpc 3. observed that the all private gateways got deleted Thanks, Jayapal Reddy
Re: Review Request: Cloudstack-702 Multiple Ip ranges in different subnets
The cool thing about this merge was that Sanjeev put in the tests for this feature much before the feature landed in master. It's a demonstration of how tests can proceed in parallel with feature development provided the FS is clear on use cases and API documentation Great work Sanjeev! I just ran the tests using the mvn + marvin + simulator integration and it already discovers a couple of failures which will be filed as bugs :) https://gist.github.com/vogxn/5575005 On Mon, May 13, 2013 at 11:40:02AM -, Koushik Das wrote: On May 13, 2013, 11:37 a.m., Koushik Das wrote: Ship It! Committed to master commit 052c24c4d1c881f791b804dbb9c2fc083af7da36 - Koushik Powered by BigRock.com
Review Request: Updated the ipaddress validation error msg for private gw and update the replace network acl
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11150/ --- Review request for cloudstack, Abhinandan Prateek and Kishan Kavala. Description --- 1. Updated the error msg for the invalid private ip address parameter 2. updated the replace network acl on private gateway for configuring default cal This addresses bug CLOUDSTACK-2400. Diffs - server/src/com/cloud/network/NetworkServiceImpl.java eeea0f2 server/src/com/cloud/network/vpc/NetworkACLServiceImpl.java ba8f489 Diff: https://reviews.apache.org/r/11150/diff/ Testing --- 1. Tested by configuring invlida ip 2. tested by configuring replacenetworkacl for private gw with default cal Thanks, Jayapal Reddy
Re: Review Request: Cloudstack-702 Multiple Ip ranges in different subnets
Good initiative Sanjeev. It would be really cool if we can follow this model as much as possible going fwd for feature development. Not to say that the feature dev shouldn't submit the integration tests :). On 14/05/13 3:58 PM, Prasanna Santhanam t...@apache.org wrote: The cool thing about this merge was that Sanjeev put in the tests for this feature much before the feature landed in master. It's a demonstration of how tests can proceed in parallel with feature development provided the FS is clear on use cases and API documentation Great work Sanjeev! I just ran the tests using the mvn + marvin + simulator integration and it already discovers a couple of failures which will be filed as bugs :) https://gist.github.com/vogxn/5575005 On Mon, May 13, 2013 at 11:40:02AM -, Koushik Das wrote: On May 13, 2013, 11:37 a.m., Koushik Das wrote: Ship It! Committed to master commit 052c24c4d1c881f791b804dbb9c2fc083af7da36 - Koushik Powered by BigRock.com
Re: Review Request: Deleting private gateways while deleting vpc in case multiple private gateways
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11149/#review20531 --- Ship it! Commit c94c71b4ce25bc12a2505547a8fdd79fa574fae3 - Kishan Kavala On May 14, 2013, 9:34 a.m., Jayapal Reddy wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11149/ --- (Updated May 14, 2013, 9:34 a.m.) Review request for cloudstack, Abhinandan Prateek, Kishan Kavala, and Alena Prokharchyk. Description --- Deleting private gateways while deleting vpc in case multiple private gateways This addresses bug CLOUDSTACK-2441. Diffs - engine/schema/src/com/cloud/network/vpc/dao/VpcGatewayDao.java 8cb5c59 engine/schema/src/com/cloud/network/vpc/dao/VpcGatewayDaoImpl.java b4d403e server/src/com/cloud/network/vpc/VpcManager.java f3b4bbc server/src/com/cloud/network/vpc/VpcManagerImpl.java fb3d41e server/test/com/cloud/vpc/MockVpcManagerImpl.java 1e2cd5f Diff: https://reviews.apache.org/r/11149/diff/ Testing --- 1. Create vpc and created more than one private gateway in this vpc 2. Deleted vpc 3. observed that the all private gateways got deleted Thanks, Jayapal Reddy
Re: Review Request: Updated the ipaddress validation error msg for private gw and update the replace network acl
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11150/#review20532 --- Ship it! commit 46f8b6f34a2a4b6c715d4850f159ff277ef6716f - Kishan Kavala On May 14, 2013, 10:29 a.m., Jayapal Reddy wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11150/ --- (Updated May 14, 2013, 10:29 a.m.) Review request for cloudstack, Abhinandan Prateek and Kishan Kavala. Description --- 1. Updated the error msg for the invalid private ip address parameter 2. updated the replace network acl on private gateway for configuring default cal This addresses bug CLOUDSTACK-2400. Diffs - server/src/com/cloud/network/NetworkServiceImpl.java eeea0f2 server/src/com/cloud/network/vpc/NetworkACLServiceImpl.java ba8f489 Diff: https://reviews.apache.org/r/11150/diff/ Testing --- 1. Tested by configuring invlida ip 2. tested by configuring replacenetworkacl for private gw with default cal Thanks, Jayapal Reddy
[ACS42] [QA] Performance Test Plan for 4.2
I am planning to execute performance test runs for 4.2 and I've posted an initial draft here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Performance+Test+Plan+for+4.2 Please take a look and let me know your feedback. A sample of the earlier performance test runs done during 4.1 (specifically for List APIs) are recorded and you can find those results here: https://cwiki.apache.org/confluence/x/8U3VAQ Thanks, Sowmya
RE: [ACS42] [QA] Performance Test Plan for 4.2
Nice! Looking forward to the results :-) Cheers, Hugo -Original Message- From: Sowmya Krishnan [mailto:sowmya.krish...@citrix.com] Sent: Tuesday, May 14, 2013 1:03 PM To: dev@cloudstack.apache.org Subject: [ACS42] [QA] Performance Test Plan for 4.2 I am planning to execute performance test runs for 4.2 and I've posted an initial draft here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Performance+Te st+Plan+for+4.2 Please take a look and let me know your feedback. A sample of the earlier performance test runs done during 4.1 (specifically for List APIs) are recorded and you can find those results here: https://cwiki.apache.org/confluence/x/8U3VAQ Thanks, Sowmya
Re: Review Request: Fix test_global_settings.py which is checking for the wrong global setting
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11006/#review20533 --- Ship it! Commit 237397df3cd27626ebffef1e274ac8404620dfa4 - Kishan Kavala On May 8, 2013, 9:15 a.m., SrikanteswaraRao Talluri wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11006/ --- (Updated May 8, 2013, 9:15 a.m.) Review request for cloudstack and Prasanna Santhanam. Description --- 1. test_global_settings.py is checking the wrong global setting while validating the updated config 2. Need to add tags - advanced, basic, devcloud etc., This addresses bug CLOUDSTACK-2382. Diffs - test/integration/smoke/test_global_settings.py a7cdb3e Diff: https://reviews.apache.org/r/11006/diff/ Testing --- tested Thanks, SrikanteswaraRao Talluri
RE: Regrading support for intel txt
Hi, -Original Message- From: Hugo Trippaers [mailto:htrippa...@schubergphilis.com] Sent: Monday, May 13, 2013 6:39 PM To: dev@cloudstack.apache.org Subject: RE: Regrading support for intel txt Heya, -Original Message- From: Devdeep Singh [mailto:devdeep.si...@citrix.com] Sent: Monday, May 13, 2013 1:28 PM To: dev@cloudstack.apache.org Subject: Regrading support for intel txt Hi, I was working on intel txt support [1] and I needed some suggestions and feedback. I am developing the feature here [2] and it has a dependency on a client library (given by intel) which is used for talking to an attestation server. Right now I am not sure under what license will the library be made available. So I have kept this feature as part of nonoss. However, it is possible that the license may be so restrictive that we cannot include it as we do for nonoss. Considering this, what are the options available? Should it be kept as a separate maven profile? Just like the other non-oss components it should have its own profile. We just use the nonoss define to activate all those profiles at once. Technically you could do a build with just the netscaler or midonet support enabled with the - P flag. Once it is resolved that the license allows nonoss or even oss, we move it there? The issue is the availability of the jar file and the availability of the api description. If the jar file is freely available for download (that is without having to login to a website or accept some eula) than we can include it in the regular build. It would be even easier if the jar would be on a maven respository. If the jar file is not available or has restrictions on distribution (like an eula or to have a valid login account) then people cannot compile the code without obtaining this library. Then we need to put it in a special profile and disable it by default. (nonoss is actually a misnomer for this) If the api is not publicly available then we can't even add code using that api to our repository. But I'm not sure if that is even possible. If we run into that we might need to have a chat with some legal types to get feedback. Let's cross that bridge only when we have to. The API library and the API documentation are behind an account which Intel provides. So should we get in touch with legal for this? If yes, who can help here? Given this, is it still possible to keep it as a separate profile which is disabled by default if legal permits? Regards, Devdeep Feel free to send the link to the library around so we can check the distribution restrictions if any. Cheers, Hugo [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Support+for+Int el+TXT+Technology [2] https://github.com/devdeep/cloudstack/tree/intel-txt Regards, Devdeep
RE: Regrading support for intel txt
Hi David, I got the library directly from intel ftp site with the username and credentials they had shared. Not sure if I can share these details publicly :(. Regards, Devdeep -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Monday, May 13, 2013 8:23 PM To: dev@cloudstack.apache.org Subject: Re: Regrading support for intel txt On Mon, May 13, 2013 at 7:27 AM, Devdeep Singh devdeep.si...@citrix.com wrote: Hi, I was working on intel txt support [1] and I needed some suggestions and feedback. I am developing the feature here [2] and it has a dependency on a client library (given by intel) which is used for talking to an attestation server. Right now I am not sure under what license will the library be made available. So I have kept this feature as part of nonoss. However, it is possible that the license may be so restrictive that we cannot include it as we do for nonoss. Considering this, what are the options available? Should it be kept as a separate maven profile? Once it is resolved that the license allows nonoss or even oss, we move it there? [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Support+for+Int el+TXT+Technology [2] https://github.com/devdeep/cloudstack/tree/intel-txt Regards, Devdeep Devdeep: First, thanks for bringing this issue to the list. I greatly appreciate it. Second: Is there a link to this library? --David
Re: Regrading support for intel txt
On Tue, May 14, 2013 at 12:33:21PM +, Devdeep Singh wrote: The API library and the API documentation are behind an account which Intel provides. So should we get in touch with legal for this? If yes, who can help here? Given this, is it still possible to keep it as a separate profile which is disabled by default if legal permits? Regards, Devdeep This is problematic IMO for 2 reasons: #1 Community angle: === If it's not possible for some to access that library, even if we make it it's own build target, then how can anyone test it? On one hand, we place a burden on ourselves in a similar way for every non-oss dependency. On the other hand, the fact that we already *sort of* deal with this already might mean that the difference is minimal WRT community issues. Have you tried asking Intel if they would switch to open publication of the library (not for open sourcing it, although that wouldn't suck). #2 Legal aspects: = Any discussion of the legal aspects will start with a copy of the license itself. We're stuck without that. We need to understand what we are dealing with here in the project first, and then we should bring any questions to legal-discuss@a.o after our initial review. -chip
RE: [WIKI] Marvin Test wiki
Nice! Thanks for writing this! --Alex -Original Message- From: Prasanna Santhanam [mailto:t...@apache.org] Sent: Monday, May 13, 2013 11:59 PM To: CloudStack Dev Subject: [WIKI] Marvin Test wiki I've rewritten most sections of the marvin wiki and organized it better now. https://cwiki.apache.org/confluence/x/QQzMAQ The earlier examples I noticed were being used to write the integration tests that the new features are including. Most of those examples were served to illustrate and not be used as is. So I've now changed the examples and also included sections for - setting up your test environment - IDE, shell, tools etc - writing the test using the libraries - debugging using the ide - running the tests from the build - extending the existing tests and some more Thanks, -- Prasanna., Powered by BigRock.com
RE: Regrading support for intel txt
-Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Tuesday, May 14, 2013 6:58 PM To: dev@cloudstack.apache.org Subject: Re: Regrading support for intel txt On Tue, May 14, 2013 at 12:33:21PM +, Devdeep Singh wrote: The API library and the API documentation are behind an account which Intel provides. So should we get in touch with legal for this? If yes, who can help here? Given this, is it still possible to keep it as a separate profile which is disabled by default if legal permits? Regards, Devdeep This is problematic IMO for 2 reasons: #1 Community angle: === If it's not possible for some to access that library, even if we make it it's own build target, then how can anyone test it? On one hand, we place a burden on ourselves in a similar way for every non-oss dependency. On the other hand, the fact that we already *sort of* deal with this already might mean that the difference is minimal WRT community issues. Have you tried asking Intel if they would switch to open publication of the library (not for open sourcing it, although that wouldn't suck). I have reached out to them regarding open publication of the library and am waiting for an answer from them. #2 Legal aspects: = Any discussion of the legal aspects will start with a copy of the license itself. We're stuck without that. We need to understand what we are dealing with here in the project first, and then we should bring any questions to legal- discuss@a.o after our initial review. I have asked them for the license text of the library. Waiting to get it from them. Regards, Devdeep -chip
Re: [PROPOSAL] VMSync improvement to better co-operate with external managers for features like HA/DRS and FT
On Mon, May 13, 2013 at 09:32:32PM -0700, Kelven Yang wrote: Murali, I've updated the document to give more background details on the thought process. I'm sorry that I'm having hard time to describe it like other normal high-level FS, since the change is at architecture level, and to understand why we are doing this makes sense from conceptual level. The document is more organized as a thought process. Actually Kelven, I appreciate reading the thought process on this one. This is one of the more useful and interesting discussions of a change like this. It's a model that I'd suggest we use again for these types of interesting architectural questions. Well done. I have one other suggested use case for you (and feel free to push back on me if you don't think it's related): Hosts placed in maintenance mode by the local element manager (ex: vSphere Virtual Center) are detected as such by ACS, as well as the reverse. This is a very common thing for a operations team that may have access to the underlying infra to do, and it would be great if it was coordinated with ACS. +1 from me on the rest of the proposal. A strong +1 on the (as you say) long road forward to promote jobs from implicit to explicit. IMO, orchestration tasks themselves are basically a combination of flow control and job control tasks for the developer. The implicit nature of job control today is, IMO, why we have different thread management implementations sprinkled around. -chip
Re: Review Request: Cloudstack-702 Multiple Ip ranges in different subnets
On Tue, May 14, 2013 at 10:42:48AM +, Nitin Mehta wrote: Good initiative Sanjeev. It would be really cool if we can follow this model as much as possible going fwd for feature development. Not to say that the feature dev shouldn't submit the integration tests :). Working together with others on a feature is a good thing! On 14/05/13 3:58 PM, Prasanna Santhanam t...@apache.org wrote: The cool thing about this merge was that Sanjeev put in the tests for this feature much before the feature landed in master. It's a demonstration of how tests can proceed in parallel with feature development provided the FS is clear on use cases and API documentation Great work Sanjeev! I just ran the tests using the mvn + marvin + simulator integration and it already discovers a couple of failures which will be filed as bugs :) https://gist.github.com/vogxn/5575005 On Mon, May 13, 2013 at 11:40:02AM -, Koushik Das wrote: On May 13, 2013, 11:37 a.m., Koushik Das wrote: Ship It! Committed to master commit 052c24c4d1c881f791b804dbb9c2fc083af7da36 - Koushik Powered by BigRock.com
Re: Regrading support for intel txt
On Tue, May 14, 2013 at 01:49:57PM +, Devdeep Singh wrote: -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Tuesday, May 14, 2013 6:58 PM To: dev@cloudstack.apache.org Subject: Re: Regrading support for intel txt On Tue, May 14, 2013 at 12:33:21PM +, Devdeep Singh wrote: The API library and the API documentation are behind an account which Intel provides. So should we get in touch with legal for this? If yes, who can help here? Given this, is it still possible to keep it as a separate profile which is disabled by default if legal permits? Regards, Devdeep This is problematic IMO for 2 reasons: #1 Community angle: === If it's not possible for some to access that library, even if we make it it's own build target, then how can anyone test it? On one hand, we place a burden on ourselves in a similar way for every non-oss dependency. On the other hand, the fact that we already *sort of* deal with this already might mean that the difference is minimal WRT community issues. Have you tried asking Intel if they would switch to open publication of the library (not for open sourcing it, although that wouldn't suck). I have reached out to them regarding open publication of the library and am waiting for an answer from them. ack - thanks #2 Legal aspects: = Any discussion of the legal aspects will start with a copy of the license itself. We're stuck without that. We need to understand what we are dealing with here in the project first, and then we should bring any questions to legal- discuss@a.o after our initial review. I have asked them for the license text of the library. Waiting to get it from them. ack - thanks - just post it to this thread (or point us to the doc URL) when you have it. Regards, Devdeep -chip
Re: [ACS42] [QA] Performance Test Plan for 4.2
On Tue, May 14, 2013 at 11:02:36AM +, Sowmya Krishnan wrote: I am planning to execute performance test runs for 4.2 and I've posted an initial draft here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Performance+Test+Plan+for+4.2 Please take a look and let me know your feedback. A sample of the earlier performance test runs done during 4.1 (specifically for List APIs) are recorded and you can find those results here: https://cwiki.apache.org/confluence/x/8U3VAQ Thanks, Sowmya +1 - this looks good!
Re: Regrading support for intel txt
On Tue, May 14, 2013 at 8:33 AM, Devdeep Singh devdeep.si...@citrix.com wrote: Hi, -Original Message- From: Hugo Trippaers [mailto:htrippa...@schubergphilis.com] Sent: Monday, May 13, 2013 6:39 PM To: dev@cloudstack.apache.org Subject: RE: Regrading support for intel txt Heya, -Original Message- From: Devdeep Singh [mailto:devdeep.si...@citrix.com] Sent: Monday, May 13, 2013 1:28 PM To: dev@cloudstack.apache.org Subject: Regrading support for intel txt Hi, I was working on intel txt support [1] and I needed some suggestions and feedback. I am developing the feature here [2] and it has a dependency on a client library (given by intel) which is used for talking to an attestation server. Right now I am not sure under what license will the library be made available. So I have kept this feature as part of nonoss. However, it is possible that the license may be so restrictive that we cannot include it as we do for nonoss. Considering this, what are the options available? Should it be kept as a separate maven profile? Just like the other non-oss components it should have its own profile. We just use the nonoss define to activate all those profiles at once. Technically you could do a build with just the netscaler or midonet support enabled with the - P flag. Once it is resolved that the license allows nonoss or even oss, we move it there? The issue is the availability of the jar file and the availability of the api description. If the jar file is freely available for download (that is without having to login to a website or accept some eula) than we can include it in the regular build. It would be even easier if the jar would be on a maven respository. If the jar file is not available or has restrictions on distribution (like an eula or to have a valid login account) then people cannot compile the code without obtaining this library. Then we need to put it in a special profile and disable it by default. (nonoss is actually a misnomer for this) If the api is not publicly available then we can't even add code using that api to our repository. But I'm not sure if that is even possible. If we run into that we might need to have a chat with some legal types to get feedback. Let's cross that bridge only when we have to. The API library and the API documentation are behind an account which Intel provides. So should we get in touch with legal for this? If yes, who can help here? Given this, is it still possible to keep it as a separate profile which is disabled by default if legal permits? Regards, Devdeep It is possible that this might not be eligible for inclusion at all, or that at a minimum we might need a separate build profile. Right now because we don't know, we simply can't begin to look towards a solution. The first step towards legal is the PMC. --David
System vm template build failed in Jenkins.cloudstack.org
Hi, System vm template creation build failed in Jenkins.cloudstack.org, not sure who is responsible for this to fix ? http://jenkins.cloudstack.org/view/master/job/build-systemvm-master/ Regards, Rayees
Review Request: Fix test_volumes.py for BVT failures
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11153/ --- Review request for cloudstack and Prasanna Santhanam. Description --- Fix test_volumes.py for BVT failures in the resize volume test and deletedetached volume test. Added basic zone tags to the tests This addresses bug CLOUDSTACK-2478. Diffs - test/integration/smoke/test_volumes.py 4bf8203 Diff: https://reviews.apache.org/r/11153/diff/ Testing --- tested Thanks, SrikanteswaraRao Talluri
Re: [jira] [Commented] (CLOUDSTACK-2463) CS Upgrade 2.2.14 to 4.1.0 failed due to no public network found (configuration : advanced network with security groups)
Jessica, How is this patch coming along? On Mon, May 13, 2013 at 8:23 PM, Jessica Wang jessica.w...@citrix.com wrote: I'll remove this option (Advance zone with SG) from UI in 4.1 branch. Will submit a patch soon. -Original Message- From: Anthony Xu [mailto:xuefei...@citrix.com] Sent: Monday, May 13, 2013 1:46 PM To: Alena Prokharchyk; dev@cloudstack.apache.org; Chip Childers Subject: RE: [jira] [Commented] (CLOUDSTACK-2463) CS Upgrade 2.2.14 to 4.1.0 failed due to no public network found (configuration : advanced network with security groups) Advance zone with SG is not in 4.1. Anthony -Original Message- From: Alena Prokharchyk Sent: Monday, May 13, 2013 1:37 PM To: dev@cloudstack.apache.org; Chip Childers; Anthony Xu Subject: Re: [jira] [Commented] (CLOUDSTACK-2463) CS Upgrade 2.2.14 to 4.1.0 failed due to no public network found (configuration : advanced network with security groups) Anthony, do we even support Advance zone with SG in 4.1? I thought you've checked it in in 4.2 only. If this is true, then: * no upgrade support for SG enabled setups to 4.1 should be provided * 4.1 UI shouldn't let you create Advance zone with SG enabled. If UI for SG enabled Advance zone was somehow merged to 4.1 branch, it should be reverted as there is no backend/db upgrade support exist there. -Alena. On 5/13/13 1:10 PM, Paul Angus paul.an...@shapeblue.com wrote: Done. :) Regards, Paul Angus S: +44 20 3603 0540 | M: +447711418784 paul.an...@shapeblue.com -Original Message- From: Wei ZHOU [mailto:ustcweiz...@gmail.com] Sent: 13 May 2013 18:38 To: dev@cloudstack.apache.org Subject: Re: [jira] [Commented] (CLOUDSTACK-2463) CS Upgrade 2.2.14 to 4.1.0 failed due to no public network found (configuration : advanced network with security groups) Thanks, Paul. Could you login to the database and paste the result of the commands Nicolas listed in Description? 2013/5/13 Paul Angus (JIRA) j...@apache.org [ https://issues.apache.org/jira/browse/CLOUDSTACK-2463?page=com.atlass i an.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentI d =13656100#comment-13656100] Paul Angus commented on CLOUDSTACK-2463: On a clean build of ACS4.1-SNAPSHOT from 13/05/13 I created an advanced zone with security groups. When attempting to enable the zone I received the following message: 'Cannot enable this Zone since: Unable to find the default physical network with traffic=Public in the specified zone id' As it was an advanced zone with security groups I didn't get the option to add/configure a public network. CS Upgrade 2.2.14 to 4.1.0 failed due to no public network found (configuration : advanced network with security groups) - - -- Key: CLOUDSTACK-2463 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2463 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.1.0 Reporter: Nicolas Lamirault Assignee: Wei Zhou Priority: Blocker Fix For: 4.1.0 According Wei Zhou last patch ( https://issues.apache.org/jira/browse/CLOUDSTACK-528), i can add a new secondary storage. The SSVM creation failed due to : 2013-05-13 15:17:52,868 DEBUG [storage.secondary.SecondaryStorageManagerImpl] (secstorage-1:null) Zone 1 is ready to launch secondary storage VM 2013-05-13 15:17:52,879 INFO [cloud.secstorage.PremiumSecondaryStorageManagerImpl] (secstorage-1:null) No running secondary storage vms found in datacenter id=1, starting one 2013-05-13 15:17:52,889 INFO [storage.secondary.SecondaryStorageManagerImpl] (secstorage-1:null) No stopped secondary storage vm is available, need to allocate a new secondary storage vm 2013-05-13 15:17:52,894 DEBUG [storage.secondary.SecondaryStorageManagerImpl] (secstorage-1:null) Assign secondary storage vm from a newly started instance for request from data center : 1 2013-05-13 15:17:52,922 WARN [cloud.vm.SystemVmLoadScanner] (secstorage-1:null) Unexpected exception Found 22 networks of type Guest when expect to find 1 com.cloud.utils.exception.CloudRuntimeException: Found 22 networks of type Guest when expect to find 1 at com.cloud.storage.secondary.SecondaryStorageManagerImpl.createSecStor a geVmInstance(SecondaryStorageManagerImpl.java:552) at com.cloud.storage.secondary.SecondaryStorageManagerImpl.startNew(Seco n daryStorageManagerImpl.java:499) at com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity ( SecondaryStorageManagerImpl.java:666) at com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(Se c
Re: [DISCUSS] Should we be releasing -beta releases?
On Tue, May 14, 2013, at 09:41 AM, Chip Childers wrote: As a way to get more user feedback on our major feature releases, what does everyone think about releasing one or two -beta releases for each major feature release? Yes to beta releases. I know that users could test at any time, but we need explicit targets for users that say now is a good time to test this and give feedback. +1 Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/
Re: [DISCUSS] Should we be releasing -beta releases?
As a relative outsider; any branch that is not released yet is a beta release. Why make it more explicit. Wouldn't this add support burdon? Make a branch 'in beta' and appoint a guard to make sure no new feartures but only fixes go in (kind of how you are working right now) Daan On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier j...@zonker.net wrote: On Tue, May 14, 2013, at 09:41 AM, Chip Childers wrote: As a way to get more user feedback on our major feature releases, what does everyone think about releasing one or two -beta releases for each major feature release? Yes to beta releases. I know that users could test at any time, but we need explicit targets for users that say now is a good time to test this and give feedback. +1 Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/
RE: [DISCUSS] Should we be releasing -beta releases?
+1 We could do an RC type thing. I wouldn't feel bad if we ship every release we vote for as a RC release. The last RC release that wins the vote will turn into the regular release. Cheers, Hugo -Original Message- From: Joe Brockmeier [mailto:j...@zonker.net] Sent: Tuesday, May 14, 2013 4:49 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Should we be releasing -beta releases? On Tue, May 14, 2013, at 09:41 AM, Chip Childers wrote: As a way to get more user feedback on our major feature releases, what does everyone think about releasing one or two -beta releases for each major feature release? Yes to beta releases. I know that users could test at any time, but we need explicit targets for users that say now is a good time to test this and give feedback. +1 Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/
Firewall rule question
This applies to both Egress firewall rules as well as IP specific firewall rules. If you specify TCP but do not specify any port details, it saves fine. I am wondering what this config implies. Does this mean that all TCP traffic is allowed? Thanks, Will
RE: [DISCUSS] Should we be releasing -beta releases?
+1 It would be much easier for planning purposes if we had target dates for betas. That would allow us to say to our user community hey, we've got something new for you to test, come and get it - instead of people having to stay up to date with the development and then choose when to start to test Noticed Daan's point about the overhead burdon, which is true, but I still think it would be better this way Kind Regards Giles D: +44 20 3603 0541 | M: +44 796 111 2055 giles.sir...@shapeblue.com -Original Message- From: Joe Brockmeier [mailto:j...@zonker.net] Sent: 14 May 2013 15:49 To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Should we be releasing -beta releases? On Tue, May 14, 2013, at 09:41 AM, Chip Childers wrote: As a way to get more user feedback on our major feature releases, what does everyone think about releasing one or two -beta releases for each major feature release? Yes to beta releases. I know that users could test at any time, but we need explicit targets for users that say now is a good time to test this and give feedback. +1 Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/ 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 operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
[ACS41] BLOCKER: No SSVM Connectivity
All,I have encountered an issue with SSVM connectivity which is outlined in ticketCLOUDSTACK-2479. Essentially, the SSVM is being created, but the management server is unable to connect to it. Additionally, I am unable to SSH to it on the link-local interface. I have outlined the environment and reproduction steps in the ticket. t am also attaching the Marvin configuration I used to define the entire zone (including the networking and secondary storage). This configuration is a known good that has worked without issue on previous 4.1 builds.Thanks,-John zone1.devcloud.cfg Description: Binary data
Re: [ACS41] BLOCKER: No SSVM Connectivity
On Tue, May 14, 2013 at 11:03:25AM -0400, John Burwell wrote: All, I have encountered an issue with SSVM connectivity which is outlined in ticket CLOUDSTACK-2479. Essentially, the SSVM is being created, but the management server is unable to connect to it. Additionally, I am unable to SSH to it on the link-local interface. I have outlined the environment and reproduction steps in the ticket. t am also attaching the Marvin configuration I used to define the entire zone (including the networking and secondary storage). This configuration is a known good that has worked without issue on previous 4.1 builds. Thanks, -John I was just talking with John on IRC about this. Two questions: Is the systemvm mvn build target actually functional in 4.1.0? The documentation that we have for the release reference the 3.x system VM template downloads, and even the IPv6 experimental system vm templates are built sort of our of band from the 4.1.0 code. If the above is true, should we resolve this bug or downgrade it? John mentioned that this build approach *was* working previously. Thoughts? -chip
Re: [DISCUSS] Should we be releasing -beta releases?
upgrades are a valid point. No one tests those as a user does. On Tue, May 14, 2013 at 4:03 PM, Chip Childers chip.child...@sungard.comwrote: On Tue, May 14, 2013 at 03:56:36PM +0100, Daan Hoogland wrote: As a relative outsider; any branch that is not released yet is a beta release. Why make it more explicit. Wouldn't this add support burdon? Make a branch 'in beta' and appoint a guard to make sure no new feartures but only fixes go in (kind of how you are working right now) So we do that today. However, a release as a -beta will get more user attention eariler in our release cycle (at least that's my theory). We need that user attention to help us ensure that upgrades work. Daan On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier j...@zonker.net wrote: On Tue, May 14, 2013, at 09:41 AM, Chip Childers wrote: As a way to get more user feedback on our major feature releases, what does everyone think about releasing one or two -beta releases for each major feature release? Yes to beta releases. I know that users could test at any time, but we need explicit targets for users that say now is a good time to test this and give feedback. +1 Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/
RE: [ANNOUNCE] New committer: Devdeep Singh
Congrats Devdeep :D -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Tuesday, May 14, 2013 5:17 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] New committer: Devdeep Singh The Project Management Committee (PMC) for Apache CloudStack has asked Devdeep Singh to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Devdeep! --Chip on behalf of the CloudStack PMC
RE: [ANNOUNCE] New committer: Devdeep Singh
Congratulations Devdeep :) -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Tuesday, May 14, 2013 8:48 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] New committer: Devdeep Singh The Project Management Committee (PMC) for Apache CloudStack has asked Devdeep Singh to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Devdeep! --Chip on behalf of the CloudStack PMC
RE: [ANNOUNCE] New committer: Devdeep Singh
Congratulations Devdeep. Regards, Sailaja.M -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Tuesday, May 14, 2013 8:48 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] New committer: Devdeep Singh The Project Management Committee (PMC) for Apache CloudStack has asked Devdeep Singh to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Devdeep! --Chip on behalf of the CloudStack PMC
Re: [ANNOUNCE] New committer: Devdeep Singh
Congrats Devdeep. - Reply message - From: Chip Childers chip.child...@sungard.com To: dev@cloudstack.apache.org dev@cloudstack.apache.org Subject: [ANNOUNCE] New committer: Devdeep Singh Date: Tue, May 14, 2013 8:47 pm The Project Management Committee (PMC) for Apache CloudStack has asked Devdeep Singh to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Devdeep! --Chip on behalf of the CloudStack PMC
Re: [ANNOUNCE] New committer: Devdeep Singh
On Tue, May 14, 2013 at 11:16:59AM -0400, Chip Childers wrote: The Project Management Committee (PMC) for Apache CloudStack has asked Devdeep Singh to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Devdeep! --Chip on behalf of the CloudStack PMC Congratulations Devdeep and thanks for all the reviews! -- Prasanna., Powered by BigRock.com
Review Request: CLOUDSTACK-2115 : [BasicZone-XenServer] Unable to add host to basic zone that is configured with bridge
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11151/ --- Review request for cloudstack, Abhinandan Prateek, Jayapal Reddy, Alex Huang, and anthony xu. Description --- Steps to reproduce: 1. Create a basic zone 2. Add a XenServer 6.1 host to CloudStack Note : before adding, have changed the following - xe-switch-network-backend bridge - update sysctl.conf with the following # Disable *tables rules for bridge traffic to increase performance net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-arptables = 1 - sysctl -p /etc/sysctl.conf This addresses bug CLOUDSTACK-2115. Diffs - scripts/vm/hypervisor/xenserver/vmops 66cde4f Diff: https://reviews.apache.org/r/11151/diff/ Testing --- Have added a Xen 6.1 which is enabled with CSP and network backend as bridge. With this fix, found that CloudStack is now issuing brctl addbr xapi0 instead of ovs commands. Thanks, venkata swamy babu budumuru
Re: [ANNOUNCE] New committer: Devdeep Singh
Congrats! :) Regards Isaac On Tue, May 14, 2013 at 11:23 PM, Prasanna Santhanam t...@apache.org wrote: On Tue, May 14, 2013 at 11:16:59AM -0400, Chip Childers wrote: The Project Management Committee (PMC) for Apache CloudStack has asked Devdeep Singh to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Devdeep! --Chip on behalf of the CloudStack PMC Congratulations Devdeep and thanks for all the reviews! -- Prasanna., Powered by BigRock.com
[DISCUSS] Backwards compatibility
Hey all, We have invested a lot of effort in creating upgrade paths from older releases to the latest version. As a sysadmin this is one of the things I value CloudStack for. However as a developers there are some drawbacks to this. It means every time we release a new version we need to QA the entire upgrade path to check if users can upgrade to this new versions. With the speed and features we are picking up, I'm expecting this to become a large burden in the near future. My proposal would be to draw a line somewhere. Personally I think it would be ok to say to a user that wants to upgrade from version 2.2.14 to 4.2 to first upgrade to version 4.0.x en than upgrade to 4.2.x. For our code it does not really matter that much, but it does matter for QA and packaging. For QA we can safely assume that the upgrades from 2.2.14 to 4.0 are covered by the 4.0 release. If we run into trouble, we release a maintenance release of that version. QA for new versions should focus on a stable upgrade path for one or two recent versions and can ignore old versions in the process. With only a few versions to test against we could also automate parts of this. For packaging it is also great. Especially with the current changes in naming (from cloud to cloudstack) and potential future changes to integrate better with distributions it becomes handy to be able to have short upgrade paths. How reasonable is it to have an upgrade path for 2.2.14 in the RPM when that rpm is built for RedHat 7. I would be in favor of supporting upgrades from the first major release in any series. For example 4.1, 4.2 and 5.0 should have a tested upgrade path from 4.0. 5.1 would have an upgrade path only from 5.0. What do you guys think? Cheers, Hugo P.S. ignore the version numbers, just used some random version numbers to illustrate my ideas.
RE: [ANNOUNCE] New committer: Devdeep Singh
Congratulations Devdeep !:) -Original Message- From: Isaac Chiang [mailto:isaacchi...@gmail.com] Sent: Tuesday, May 14, 2013 8:59 PM To: dev@cloudstack.apache.org Subject: Re: [ANNOUNCE] New committer: Devdeep Singh Congrats! :) Regards Isaac On Tue, May 14, 2013 at 11:23 PM, Prasanna Santhanam t...@apache.org wrote: On Tue, May 14, 2013 at 11:16:59AM -0400, Chip Childers wrote: The Project Management Committee (PMC) for Apache CloudStack has asked Devdeep Singh to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Devdeep! --Chip on behalf of the CloudStack PMC Congratulations Devdeep and thanks for all the reviews! -- Prasanna., Powered by BigRock.com
RE: [DISCUSS] Backwards compatibility
+1 Regards Geoff Higginbottom D: +44 20 3603 0542 | S: +44 20 3603 0540 | M: +447968161581 geoff.higginbot...@shapeblue.com -Original Message- From: Hugo Trippaers [mailto:htrippa...@schubergphilis.com] Sent: 14 May 2013 16:34 To: 'dev@cloudstack.apache.org' Subject: [DISCUSS] Backwards compatibility Hey all, We have invested a lot of effort in creating upgrade paths from older releases to the latest version. As a sysadmin this is one of the things I value CloudStack for. However as a developers there are some drawbacks to this. It means every time we release a new version we need to QA the entire upgrade path to check if users can upgrade to this new versions. With the speed and features we are picking up, I'm expecting this to become a large burden in the near future. My proposal would be to draw a line somewhere. Personally I think it would be ok to say to a user that wants to upgrade from version 2.2.14 to 4.2 to first upgrade to version 4.0.x en than upgrade to 4.2.x. For our code it does not really matter that much, but it does matter for QA and packaging. For QA we can safely assume that the upgrades from 2.2.14 to 4.0 are covered by the 4.0 release. If we run into trouble, we release a maintenance release of that version. QA for new versions should focus on a stable upgrade path for one or two recent versions and can ignore old versions in the process. With only a few versions to test against we could also automate parts of this. For packaging it is also great. Especially with the current changes in naming (from cloud to cloudstack) and potential future changes to integrate better with distributions it becomes handy to be able to have short upgrade paths. How reasonable is it to have an upgrade path for 2.2.14 in the RPM when that rpm is built for RedHat 7. I would be in favor of supporting upgrades from the first major release in any series. For example 4.1, 4.2 and 5.0 should have a tested upgrade path from 4.0. 5.1 would have an upgrade path only from 5.0. What do you guys think? Cheers, Hugo P.S. ignore the version numbers, just used some random version numbers to illustrate my ideas. 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 operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Review Request: CLOUDSTACK-2130: UpdateDefaultNicForVirtualMachine api should also create usage events for updating new default network
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11156/ --- Review request for cloudstack and mice xia. Description --- When we call UpdateDefaultNicForVirtualMachine we should call appropriate usage events as well for updating information related to default nic for proper usage calculation. Added 4 usage events : 2 for network.offerings.remove and 2 for network.offerings.assign Events are : network.offerings.assign for new nic to be made default, network.offerings.remove for removal of non-default network.offerings.assign for old default nic to be made non default and network.offerings.remove for removal of default. This addresses bug 2130. Diffs - server/src/com/cloud/vm/UserVmManagerImpl.java 0f6adc0 Diff: https://reviews.apache.org/r/11156/diff/ Testing --- Tested manually. Rat build passed. Rebased to latest master. Thanks, Saksham Srivastava
Re: [ACS41] CLOUDSTACK-2064 - Help needed on VMware related bug!
Kelven: Any chance you can help with this? If not, anyone you'd recommend to pick this up? --David On Tue, May 14, 2013 at 10:28 AM, Chip Childers chip.child...@sungard.com wrote: On Mon, May 13, 2013 at 02:17:21PM -0400, Chip Childers wrote: CLOUDSTACK-2064 - The Vmware template dosent have permissions to be copied from secondary storage. I need someone to grab this one and work on resolving it please! -chip Help is still needed on this bug. Anyone care to review / fix it? I believe it is the last issue before the next 4.1.0 release VOTE. -chip
RE: [DISCUSS] Backwards compatibility
+1 Hugo - I think that's a very pragmatic approach. Whilst it would be great to upgrade any version to any other version, I think most people are used to sequential paths for upgrade of server platforms. Kind Regards Giles D: +44 20 3603 0541 | M: +44 796 111 2055 giles.sir...@shapeblue.com -Original Message- From: Hugo Trippaers [mailto:htrippa...@schubergphilis.com] Sent: 14 May 2013 16:34 To: 'dev@cloudstack.apache.org' Subject: [DISCUSS] Backwards compatibility Hey all, We have invested a lot of effort in creating upgrade paths from older releases to the latest version. As a sysadmin this is one of the things I value CloudStack for. However as a developers there are some drawbacks to this. It means every time we release a new version we need to QA the entire upgrade path to check if users can upgrade to this new versions. With the speed and features we are picking up, I'm expecting this to become a large burden in the near future. My proposal would be to draw a line somewhere. Personally I think it would be ok to say to a user that wants to upgrade from version 2.2.14 to 4.2 to first upgrade to version 4.0.x en than upgrade to 4.2.x. For our code it does not really matter that much, but it does matter for QA and packaging. For QA we can safely assume that the upgrades from 2.2.14 to 4.0 are covered by the 4.0 release. If we run into trouble, we release a maintenance release of that version. QA for new versions should focus on a stable upgrade path for one or two recent versions and can ignore old versions in the process. With only a few versions to test against we could also automate parts of this. For packaging it is also great. Especially with the current changes in naming (from cloud to cloudstack) and potential future changes to integrate better with distributions it becomes handy to be able to have short upgrade paths. How reasonable is it to have an upgrade path for 2.2.14 in the RPM when that rpm is built for RedHat 7. I would be in favor of supporting upgrades from the first major release in any series. For example 4.1, 4.2 and 5.0 should have a tested upgrade path from 4.0. 5.1 would have an upgrade path only from 5.0. What do you guys think? Cheers, Hugo P.S. ignore the version numbers, just used some random version numbers to illustrate my ideas. 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 operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: [DISCUSS] Backwards compatibility
On Tue, May 14, 2013 at 03:34:00PM +, Hugo Trippaers wrote: Hey all, We have invested a lot of effort in creating upgrade paths from older releases to the latest version. As a sysadmin this is one of the things I value CloudStack for. However as a developers there are some drawbacks to this. It means every time we release a new version we need to QA the entire upgrade path to check if users can upgrade to this new versions. With the speed and features we are picking up, I'm expecting this to become a large burden in the near future. My proposal would be to draw a line somewhere. Personally I think it would be ok to say to a user that wants to upgrade from version 2.2.14 to 4.2 to first upgrade to version 4.0.x en than upgrade to 4.2.x. For our code it does not really matter that much, but it does matter for QA and packaging. For QA we can safely assume that the upgrades from 2.2.14 to 4.0 are covered by the 4.0 release. If we run into trouble, we release a maintenance release of that version. QA for new versions should focus on a stable upgrade path for one or two recent versions and can ignore old versions in the process. With only a few versions to test against we could also automate parts of this. For packaging it is also great. Especially with the current changes in naming (from cloud to cloudstack) and potential future changes to integrate better with distributions it becomes handy to be able to have short upgrade paths. How reasonable is it to have an upgrade path for 2.2.14 in the RPM when that rpm is built for RedHat 7. I would be in favor of supporting upgrades from the first major release in any series. For example 4.1, 4.2 and 5.0 should have a tested upgrade path from 4.0. 5.1 would have an upgrade path only from 5.0. What do you guys think? Cheers, Hugo P.S. ignore the version numbers, just used some random version numbers to illustrate my ideas. I think that this is reasonable, as long as there *IS* a path to get from any version X (2.0 and up) to any version Y (4.0 and up). I'd -1 any approach that doesn't provide a path in all cases (multi-hop is a path). BTW, we'll have to document the heck out of this... we do not want any confusion. And frankly, we should even consider throwing an error and not processing an upgrade that hasn't been tested if we do this.
RE: [ANNOUNCE] New committer: Devdeep Singh
Congrats Devdeep Party time :-) :-) :-) -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Tuesday, May 14, 2013 8:47 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] New committer: Devdeep Singh The Project Management Committee (PMC) for Apache CloudStack has asked Devdeep Singh to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Devdeep! --Chip on behalf of the CloudStack PMC
Re: [DISCUSS] Backwards compatibility
On Tue, May 14, 2013 at 09:39:15PM +0530, Prasanna Santhanam wrote: There's proven methods of doing database change managment [1] and we've taken a good first step in establishing a base schema [2] at 4.0. It's probably the right time to think about these things now that 4.1 has been stalling for a while with upgrade issues. [1] http://blog.42.nl/articles/automate-liquibase-migrations/ Right blog link: http://blog.42.nl/articles/bridging-the-divide-between-java-and-the-database-with-liquibase/ -- Prasanna., Powered by BigRock.com
Re: [DISCUSS] Backwards compatibility
+1 Wei 2013/5/14 Hugo Trippaers htrippa...@schubergphilis.com Hey all, We have invested a lot of effort in creating upgrade paths from older releases to the latest version. As a sysadmin this is one of the things I value CloudStack for. However as a developers there are some drawbacks to this. It means every time we release a new version we need to QA the entire upgrade path to check if users can upgrade to this new versions. With the speed and features we are picking up, I'm expecting this to become a large burden in the near future. My proposal would be to draw a line somewhere. Personally I think it would be ok to say to a user that wants to upgrade from version 2.2.14 to 4.2 to first upgrade to version 4.0.x en than upgrade to 4.2.x. For our code it does not really matter that much, but it does matter for QA and packaging. For QA we can safely assume that the upgrades from 2.2.14 to 4.0 are covered by the 4.0 release. If we run into trouble, we release a maintenance release of that version. QA for new versions should focus on a stable upgrade path for one or two recent versions and can ignore old versions in the process. With only a few versions to test against we could also automate parts of this. For packaging it is also great. Especially with the current changes in naming (from cloud to cloudstack) and potential future changes to integrate better with distributions it becomes handy to be able to have short upgrade paths. How reasonable is it to have an upgrade path for 2.2.14 in the RPM when that rpm is built for RedHat 7. I would be in favor of supporting upgrades from the first major release in any series. For example 4.1, 4.2 and 5.0 should have a tested upgrade path from 4.0. 5.1 would have an upgrade path only from 5.0. What do you guys think? Cheers, Hugo P.S. ignore the version numbers, just used some random version numbers to illustrate my ideas.
Re: Review Request: CLOUDSTACK-2115 : [BasicZone-XenServer] Unable to add host to basic zone that is configured with bridge
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11151/#review20537 --- LGTM. Fairly straightforward to strip the word endings. Any concerns? I'll merge this tomorrow if none. - Prasanna Santhanam On May 14, 2013, 3:28 p.m., venkata swamy babu budumuru wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11151/ --- (Updated May 14, 2013, 3:28 p.m.) Review request for cloudstack, Abhinandan Prateek, Jayapal Reddy, Alex Huang, and anthony xu. Description --- Steps to reproduce: 1. Create a basic zone 2. Add a XenServer 6.1 host to CloudStack Note : before adding, have changed the following - xe-switch-network-backend bridge - update sysctl.conf with the following # Disable *tables rules for bridge traffic to increase performance net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-arptables = 1 - sysctl -p /etc/sysctl.conf This addresses bug CLOUDSTACK-2115. Diffs - scripts/vm/hypervisor/xenserver/vmops 66cde4f Diff: https://reviews.apache.org/r/11151/diff/ Testing --- Have added a Xen 6.1 which is enabled with CSP and network backend as bridge. With this fix, found that CloudStack is now issuing brctl addbr xapi0 instead of ovs commands. Thanks, venkata swamy babu budumuru
Re: [DISCUSS] Backwards compatibility
On Tue, May 14, 2013 at 11:34 AM, Hugo Trippaers htrippa...@schubergphilis.com wrote: Hey all, We have invested a lot of effort in creating upgrade paths from older releases to the latest version. As a sysadmin this is one of the things I value CloudStack for. However as a developers there are some drawbacks to this. It means every time we release a new version we need to QA the entire upgrade path to check if users can upgrade to this new versions. With the speed and features we are picking up, I'm expecting this to become a large burden in the near future. My proposal would be to draw a line somewhere. Personally I think it would be ok to say to a user that wants to upgrade from version 2.2.14 to 4.2 to first upgrade to version 4.0.x en than upgrade to 4.2.x. For our code it does not really matter that much, but it does matter for QA and packaging. For QA we can safely assume that the upgrades from 2.2.14 to 4.0 are covered by the 4.0 release. If we run into trouble, we release a maintenance release of that version. QA for new versions should focus on a stable upgrade path for one or two recent versions and can ignore old versions in the process. With only a few versions to test against we could also automate parts of this. For packaging it is also great. Especially with the current changes in naming (from cloud to cloudstack) and potential future changes to integrate better with distributions it becomes handy to be able to have short upgrade paths. How reasonable is it to have an upgrade path for 2.2.14 in the RPM when that rpm is built for RedHat 7. I would be in favor of supporting upgrades from the first major release in any series. For example 4.1, 4.2 and 5.0 should have a tested upgrade path from 4.0. 5.1 would have an upgrade path only from 5.0. What do you guys think? Cheers, Hugo P.S. ignore the version numbers, just used some random version numbers to illustrate my ideas. While I generally like this idea - orphaned features have essentially long-stranded folks on old version with no way of upgrade. Think of things like Bare metal, Oracle VM, SG in Advanced Zones, etc. For some of those, I don't see how we'll not have them upgrade from 2.2.x to 4.2. The sysadmin in me thinks we've done a moderate job of supporting upgrades in the past - for some core set of services we've done well, but used anything not 'mainstream' and we have left many folks behind. A lot of that is pre-ASF legacy that for better or worse we still need to deal with. For folks that have used such things, we have essentially abandoned them on whatever version they used them. I think that this should mean that we are much more sober in adding features, to gauge how well we as a community can support those features over the long haul. It also means that deprecations need to be planned. The way we deprecated Oracle VM was horrendous IMO.
Re: [DISCUSS] Should we be releasing -beta releases?
On Tue, May 14, 2013 at 11:59:14AM -0400, David Nalley wrote: Are you going to support upgrades from your Betas to release (and betaN to betaN+1)? If the answer is no, then there is no interest on my part. It's not better than us producing nightly builds, or highlighting jenkins builds. Perhaps doing a better job of highlighting nightly builds at key moments is the right answer to the problem I was trying to solve (more user testing of upgrades)? The beta idea comes with some overhead, and perhaps that overhead isn't worth the benefit (if there are other ways to achieve that goal). And that's why I floated the idea... to get reactions. On Tue, May 14, 2013 at 11:03 AM, Chip Childers chip.child...@sungard.com wrote: On Tue, May 14, 2013 at 03:56:36PM +0100, Daan Hoogland wrote: As a relative outsider; any branch that is not released yet is a beta release. Why make it more explicit. Wouldn't this add support burdon? Make a branch 'in beta' and appoint a guard to make sure no new feartures but only fixes go in (kind of how you are working right now) So we do that today. However, a release as a -beta will get more user attention eariler in our release cycle (at least that's my theory). We need that user attention to help us ensure that upgrades work. Daan On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier j...@zonker.net wrote: On Tue, May 14, 2013, at 09:41 AM, Chip Childers wrote: As a way to get more user feedback on our major feature releases, what does everyone think about releasing one or two -beta releases for each major feature release? Yes to beta releases. I know that users could test at any time, but we need explicit targets for users that say now is a good time to test this and give feedback. +1 Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/
Re: [ACS41] BLOCKER: No SSVM Connectivity
On Tue, May 14, 2013 at 11:03:25AM -0400, John Burwell wrote: All, I have encountered an issue with SSVM connectivity which is outlined in ticket CLOUDSTACK-2479. Essentially, the SSVM is being created, but the management server is unable to connect to it. Additionally, I am unable to SSH to it on the link-local interface. I have outlined the environment and reproduction steps in the ticket. t am also attaching the Marvin configuration I used to define the entire zone (including the networking and secondary storage). This configuration is a known good that has worked without issue on previous 4.1 builds. Thanks, -John John used the installation guide and had the same results as last time. Anyone willing to help?
Re: [ACS41] CLOUDSTACK-2064 - Help needed on VMware related bug!
On Tue, May 14, 2013 at 11:52:08AM -0400, David Nalley wrote: Kelven: Any chance you can help with this? If not, anyone you'd recommend to pick this up? --David On Tue, May 14, 2013 at 10:28 AM, Chip Childers chip.child...@sungard.com wrote: On Mon, May 13, 2013 at 02:17:21PM -0400, Chip Childers wrote: CLOUDSTACK-2064 - The Vmware template dosent have permissions to be copied from secondary storage. I need someone to grab this one and work on resolving it please! -chip Help is still needed on this bug. Anyone care to review / fix it? I believe it is the last issue before the next 4.1.0 release VOTE. -chip Hugo has marked this one as resolved / won't fix. He notes that it appears to be a local system permission issue. If someone disagrees, please re-open it. -chip
Re: [ANNOUNCE] New committer: Devdeep Singh
Congrats Devdeep! On Tue, May 14, 2013 at 8:46 PM, Chip Childers chip.child...@sungard.comwrote: The Project Management Committee (PMC) for Apache CloudStack has asked Devdeep Singh to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Devdeep! --Chip on behalf of the CloudStack PMC
Re: version of cloudmonkey
Hey Justin, Just checking in on this... if you give us your pypi username I'd be happy to give you the rights to push SNAPs to pypi for cloudmonkey. On Sat, May 4, 2013 at 3:02 PM, Rohit Yadav bhais...@apache.org wrote: On Thu, May 2, 2013 at 5:04 PM, Justin Grudzien grudz...@gmail.com wrote: When I become reliable I am certainly willing to learn how to do it. While one can disagree with me, I feel everyone who is part of the community should be reliable until proven guilty or whatnot. Justin, register for an account on pypi and share with me your user id. On pypi try to upload a fake package just to understand how pypi works. As agreed in earlier threads, we will never publish a versioned pkg without community vote (there won't be any separate thing, when our release will ask to vote on a release, that includes all the components of that release i.e. cloudmonkey, awsapi, api, utils etc.). Though we will publish snapshots (or latest src dists) with cloudmonkey-cloudstack-target-version-snapshotincremental nos., so when one does: pip install cloudmonkey = gets latest. (the community version) pip install cloudmonkey==4.1 = gets cloudmonkey 4.1 (the release version) Though the actual/official source dist. will be published on apache's infra (pypi is a channel outside of ASF but quite popular and works with pip/easy_install). Cheers. Justin Sent from my iPhone On May 2, 2013, at 5:50 AM, Rohit Yadav bhais...@apache.org wrote: On Thu, May 2, 2013 at 4:30 AM, Justin Grudzien grudz...@gmail.comwrote: It is currently in master but I will see if I can get Rohit, who I think owns the process, to create a new version for pip. If that isn't immediately possible I can revert the documentation until it is done. I figured documentation is always last :) Hey, I don't own the process just help publish snapshots. Chip has access to the pypi release channel as well, and any committer/pmc/reliable-contributor can gain the access. Will take a look at it and try to publish latest snapshot from master this weekend (but no promises :) Cheers. Justin On May 1, 2013, at 4:06 PM, Marcus Sorensen shadow...@gmail.com wrote: The wiki was the one that had the 'display' parameter shown. I'm assuming the display parameter is only in master then? On Wed, May 1, 2013 at 2:56 PM, Justin Grudzien grudz...@gmail.com wrote: Which documentation are you referring to? I updated cloudmonkey to add the set display and I updated the wiki to include the changes. I also noticed the async issue but haven't gotten around to fixing it yet. On Wed, May 1, 2013 at 8:47 AM, Marcus Sorensen shadow...@gmail.com wrote: I noticed that the documentation doesn't quite match up with cloudmonkey as installed via tools/cli, nor does it match the tarball. It seems to be missing 'set display', among other things, and the asyncblock never returns, in either version, long after the job is finished.
RE: Review Request: Cloudstack-702 Multiple Ip ranges in different subnets
-Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Tuesday, May 14, 2013 7:00 AM To: dev@cloudstack.apache.org Cc: Sanjeev Neelarapu Subject: Re: Review Request: Cloudstack-702 Multiple Ip ranges in different subnets On Tue, May 14, 2013 at 10:42:48AM +, Nitin Mehta wrote: Good initiative Sanjeev. It would be really cool if we can follow this model as much as possible going fwd for feature development. Not to say that the feature dev shouldn't submit the integration tests :). Working together with others on a feature is a good thing! [Animesh] Test Driven Development helps clarify requirements early on and results in better quality code and this is the only way you can guarantee that you have full automation coverage. Good job Sanjeev On 14/05/13 3:58 PM, Prasanna Santhanam t...@apache.org wrote: The cool thing about this merge was that Sanjeev put in the tests for this feature much before the feature landed in master. It's a demonstration of how tests can proceed in parallel with feature development provided the FS is clear on use cases and API documentation Great work Sanjeev! I just ran the tests using the mvn + marvin + simulator integration and it already discovers a couple of failures which will be filed as bugs :) https://gist.github.com/vogxn/5575005 On Mon, May 13, 2013 at 11:40:02AM -, Koushik Das wrote: On May 13, 2013, 11:37 a.m., Koushik Das wrote: Ship It! Committed to master commit 052c24c4d1c881f791b804dbb9c2fc083af7da36 - Koushik Powered by BigRock.com
Re: [DISCUSS] Backwards compatibility
Sent from my iPhone On 14 mei 2013, at 18:28, David Nalley da...@gnsa.us wrote: On Tue, May 14, 2013 at 11:34 AM, Hugo Trippaers htrippa...@schubergphilis.com wrote: Hey all, We have invested a lot of effort in creating upgrade paths from older releases to the latest version. As a sysadmin this is one of the things I value CloudStack for. However as a developers there are some drawbacks to this. It means every time we release a new version we need to QA the entire upgrade path to check if users can upgrade to this new versions. With the speed and features we are picking up, I'm expecting this to become a large burden in the near future. My proposal would be to draw a line somewhere. Personally I think it would be ok to say to a user that wants to upgrade from version 2.2.14 to 4.2 to first upgrade to version 4.0.x en than upgrade to 4.2.x. For our code it does not really matter that much, but it does matter for QA and packaging. For QA we can safely assume that the upgrades from 2.2.14 to 4.0 are covered by the 4.0 release. If we run into trouble, we release a maintenance release of that version. QA for new versions should focus on a stable upgrade path for one or two recent versions and can ignore old versions in the process. With only a few versions to test against we could also automate parts of this. For packaging it is also great. Especially with the current changes in naming (from cloud to cloudstack) and potential future changes to integrate better with distributions it becomes handy to be able to have short upgrade paths. How reasonable is it to have an upgrade path for 2.2.14 in the RPM when that rpm is built for RedHat 7. I would be in favor of supporting upgrades from the first major release in any series. For example 4.1, 4.2 and 5.0 should have a tested upgrade path from 4.0. 5.1 would have an upgrade path only from 5.0. What do you guys think? Cheers, Hugo P.S. ignore the version numbers, just used some random version numbers to illustrate my ideas. While I generally like this idea - orphaned features have essentially long-stranded folks on old version with no way of upgrade. Think of things like Bare metal, Oracle VM, SG in Advanced Zones, etc. For some of those, I don't see how we'll not have them upgrade from 2.2.x to 4.2. The sysadmin in me thinks we've done a moderate job of supporting upgrades in the past - for some core set of services we've done well, but used anything not 'mainstream' and we have left many folks behind. A lot of that is pre-ASF legacy that for better or worse we still need to deal with. For folks that have used such things, we have essentially abandoned them on whatever version they used them. I think that this should mean that we are much more sober in adding features, to gauge how well we as a community can support those features over the long haul. It also means that deprecations need to be planned. The way we deprecated Oracle VM was horrendous IMO. You are actually introducing a second point here. My point was that if we have a stable upgrade path from say version 2.2.14 to 4.0 then 4.1 would only need to have an upgrade from 4.0 to 4.1. So admins would have to do two different upgrades (talking about packages installed on systems) in instead of one as is the case now. Your point, if I'm getting it right is about abandoning features and thereby users. That's something we agree on, we shouldn't so easily deprecate features as we go along. Or at least be very clear about this and explain why. I think this warrants a separate thread to discuss this in more detail. Cheers, Hugo
Re: [DISCUSS] Backwards compatibility
On Tue, May 14, 2013 at 1:46 PM, Hugo Trippaers htrippa...@schubergphilis.com wrote: Sent from my iPhone On 14 mei 2013, at 18:28, David Nalley da...@gnsa.us wrote: On Tue, May 14, 2013 at 11:34 AM, Hugo Trippaers htrippa...@schubergphilis.com wrote: Hey all, We have invested a lot of effort in creating upgrade paths from older releases to the latest version. As a sysadmin this is one of the things I value CloudStack for. However as a developers there are some drawbacks to this. It means every time we release a new version we need to QA the entire upgrade path to check if users can upgrade to this new versions. With the speed and features we are picking up, I'm expecting this to become a large burden in the near future. My proposal would be to draw a line somewhere. Personally I think it would be ok to say to a user that wants to upgrade from version 2.2.14 to 4.2 to first upgrade to version 4.0.x en than upgrade to 4.2.x. For our code it does not really matter that much, but it does matter for QA and packaging. For QA we can safely assume that the upgrades from 2.2.14 to 4.0 are covered by the 4.0 release. If we run into trouble, we release a maintenance release of that version. QA for new versions should focus on a stable upgrade path for one or two recent versions and can ignore old versions in the process. With only a few versions to test against we could also automate parts of this. For packaging it is also great. Especially with the current changes in naming (from cloud to cloudstack) and potential future changes to integrate better with distributions it becomes handy to be able to have short upgrade paths. How reasonable is it to have an upgrade path for 2.2.14 in the RPM when that rpm is built for RedHat 7. I would be in favor of supporting upgrades from the first major release in any series. For example 4.1, 4.2 and 5.0 should have a tested upgrade path from 4.0. 5.1 would have an upgrade path only from 5.0. What do you guys think? Cheers, Hugo P.S. ignore the version numbers, just used some random version numbers to illustrate my ideas. While I generally like this idea - orphaned features have essentially long-stranded folks on old version with no way of upgrade. Think of things like Bare metal, Oracle VM, SG in Advanced Zones, etc. For some of those, I don't see how we'll not have them upgrade from 2.2.x to 4.2. The sysadmin in me thinks we've done a moderate job of supporting upgrades in the past - for some core set of services we've done well, but used anything not 'mainstream' and we have left many folks behind. A lot of that is pre-ASF legacy that for better or worse we still need to deal with. For folks that have used such things, we have essentially abandoned them on whatever version they used them. I think that this should mean that we are much more sober in adding features, to gauge how well we as a community can support those features over the long haul. It also means that deprecations need to be planned. The way we deprecated Oracle VM was horrendous IMO. You are actually introducing a second point here. Yes, I did - sorry about that, but I think it is part of the conversation, because in many cases they created the problem. See below as to why. My point was that if we have a stable upgrade path from say version 2.2.14 to 4.0 then 4.1 would only need to have an upgrade from 4.0 to 4.1. So admins would have to do two different upgrades (talking about packages installed on systems) in instead of one as is the case now. The problem is that we have many that can't upgrade from 2.2.14 to 4.0 right now. I think 2.2.14 to 4.1 is the closest we'll get, but wouldn't rool out 2.2.14 4.2 in some cases. (I know, we are ignoring version numbers. I think this is fine if we put a stake in the ground and say we'll get you from 2.2.14 to the jumping off release, but won't test past that) Your point, if I'm getting it right is about abandoning features and thereby users. That's something we agree on, we shouldn't so easily deprecate features as we go along. Or at least be very clear about this and explain why. I think this warrants a separate thread to discuss this in more detail. Agreed - maybe I'll start that one soon. --David
Re: [ANNOUNCE] New committer: Devdeep Singh
Awesome! Congrats Devdeep. On Tue, May 14, 2013 at 9:57 AM, Rohit Yadav bhais...@apache.org wrote: Congrats Devdeep! On Tue, May 14, 2013 at 8:46 PM, Chip Childers chip.child...@sungard.com wrote: The Project Management Committee (PMC) for Apache CloudStack has asked Devdeep Singh to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Devdeep! --Chip on behalf of the CloudStack PMC
Re: [DISCUSS] Should we be releasing -beta releases?
+1 I feel this allows for users who are chomping at the bit to get a hold of feature X. Tinker with feature X, expose bugs or use case issues well before an official release. Saves on the disappointment as well. ;) On Tue, May 14, 2013 at 9:34 AM, Chip Childers chip.child...@sungard.comwrote: On Tue, May 14, 2013 at 11:59:14AM -0400, David Nalley wrote: Are you going to support upgrades from your Betas to release (and betaN to betaN+1)? If the answer is no, then there is no interest on my part. It's not better than us producing nightly builds, or highlighting jenkins builds. Perhaps doing a better job of highlighting nightly builds at key moments is the right answer to the problem I was trying to solve (more user testing of upgrades)? The beta idea comes with some overhead, and perhaps that overhead isn't worth the benefit (if there are other ways to achieve that goal). And that's why I floated the idea... to get reactions. On Tue, May 14, 2013 at 11:03 AM, Chip Childers chip.child...@sungard.com wrote: On Tue, May 14, 2013 at 03:56:36PM +0100, Daan Hoogland wrote: As a relative outsider; any branch that is not released yet is a beta release. Why make it more explicit. Wouldn't this add support burdon? Make a branch 'in beta' and appoint a guard to make sure no new feartures but only fixes go in (kind of how you are working right now) So we do that today. However, a release as a -beta will get more user attention eariler in our release cycle (at least that's my theory). We need that user attention to help us ensure that upgrades work. Daan On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier j...@zonker.net wrote: On Tue, May 14, 2013, at 09:41 AM, Chip Childers wrote: As a way to get more user feedback on our major feature releases, what does everyone think about releasing one or two -beta releases for each major feature release? Yes to beta releases. I know that users could test at any time, but we need explicit targets for users that say now is a good time to test this and give feedback. +1 Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/
Re: Firewall rule question
I'm hoping thats not the default behavior, and nothing happens on the firewall. I guess the fact that empty values entered returns success is a bug? On Tue, May 14, 2013 at 8:00 AM, Will Stevens wstev...@cloudops.com wrote: This applies to both Egress firewall rules as well as IP specific firewall rules. If you specify TCP but do not specify any port details, it saves fine. I am wondering what this config implies. Does this mean that all TCP traffic is allowed? Thanks, Will
RE: [DISCUSS] Should we be releasing -beta releases?
+1 to what Ahmad says here . Perfect reasoning . There have been many users on the list asking for some capability /feature present in CloudStack when it's actually under development in the current release. Beta release would allow them to get a feel of it . Definitely , it would help to further refine any new feature further when actually tested in a production environment . -Original Message- From: Ahmad Emneina [mailto:aemne...@gmail.com] Sent: Wednesday, May 15, 2013 12:07 AM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Should we be releasing -beta releases? +1 I feel this allows for users who are chomping at the bit to get a hold of feature X. Tinker with feature X, expose bugs or use case issues well before an official release. Saves on the disappointment as well. ;) On Tue, May 14, 2013 at 9:34 AM, Chip Childers chip.child...@sungard.comwrote: On Tue, May 14, 2013 at 11:59:14AM -0400, David Nalley wrote: Are you going to support upgrades from your Betas to release (and betaN to betaN+1)? If the answer is no, then there is no interest on my part. It's not better than us producing nightly builds, or highlighting jenkins builds. Perhaps doing a better job of highlighting nightly builds at key moments is the right answer to the problem I was trying to solve (more user testing of upgrades)? The beta idea comes with some overhead, and perhaps that overhead isn't worth the benefit (if there are other ways to achieve that goal). And that's why I floated the idea... to get reactions. On Tue, May 14, 2013 at 11:03 AM, Chip Childers chip.child...@sungard.com wrote: On Tue, May 14, 2013 at 03:56:36PM +0100, Daan Hoogland wrote: As a relative outsider; any branch that is not released yet is a beta release. Why make it more explicit. Wouldn't this add support burdon? Make a branch 'in beta' and appoint a guard to make sure no new feartures but only fixes go in (kind of how you are working right now) So we do that today. However, a release as a -beta will get more user attention eariler in our release cycle (at least that's my theory). We need that user attention to help us ensure that upgrades work. Daan On Tue, May 14, 2013 at 3:49 PM, Joe Brockmeier j...@zonker.net wrote: On Tue, May 14, 2013, at 09:41 AM, Chip Childers wrote: As a way to get more user feedback on our major feature releases, what does everyone think about releasing one or two -beta releases for each major feature release? Yes to beta releases. I know that users could test at any time, but we need explicit targets for users that say now is a good time to test this and give feedback. +1 Best, jzb -- Joe Brockmeier j...@zonker.net Twitter: @jzb http://www.dissociatedpress.net/
Re: [ACS41] CLOUDSTACK-2463 Patch?
On Tue, May 14, 2013 at 11:39:11AM -0700, Jessica Wang wrote: Chip, Brian will provide the UI patch (to hide Advanced zone with Security Groups option from UI). Fantastic! Thanks folks. -chip Jessica -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Tuesday, May 14, 2013 11:09 AM To: dev@cloudstack.apache.org; Jessica Wang Subject: [ACS41] CLOUDSTACK-2463 Patch? Jessica, How's the UI patch you mentioned coming along? Any ETA? -chip
Re: Firewall rule question
Ya, I am not sure. I am working off a master branch from about 2-3 weeks ago. I was kind of expecting it to error and it didn't, so it was not clear how that case would behave. I am currently developing an integration with the Palo Alto firewall and they don't support specifying a protocol like TCP without any port information. I still have to finalize the logic associated with that edge case, so I wanted to understand what the expected behaviour was from that config. On Tue, May 14, 2013 at 2:41 PM, Ahmad Emneina aemne...@gmail.com wrote: I'm hoping thats not the default behavior, and nothing happens on the firewall. I guess the fact that empty values entered returns success is a bug? On Tue, May 14, 2013 at 8:00 AM, Will Stevens wstev...@cloudops.com wrote: This applies to both Egress firewall rules as well as IP specific firewall rules. If you specify TCP but do not specify any port details, it saves fine. I am wondering what this config implies. Does this mean that all TCP traffic is allowed? Thanks, Will
Review Request: Fix base.py for volume migrate method
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11163/ --- Review request for cloudstack and Prasanna Santhanam. Description --- Add @classmethod decorator to migrate method in Volume class in base.py This addresses bug CLOUDSTACK-2483. Diffs - tools/marvin/marvin/integration/lib/base.py ecdc841 Diff: https://reviews.apache.org/r/11163/diff/ Testing --- tested Thanks, SrikanteswaraRao Talluri
Re: [MERGE]PVLAN branch to MASTER(v2)
On Mon, May 13, 2013 at 6:58 PM, Chip Childers chipchild...@apache.orgwrote: On Mon, May 13, 2013 at 03:16:28PM -0700, Sheng Yang wrote: FS at: https://cwiki.apache.org/CLOUDSTACK/pvlan-for-isolation-within-a-vlan.html PVLAN branch has been under development for some time, and now the functionality works on KVM and Xen, would be followed by VMware soon VM live migration is not supported so far. Code is ready basically, but I am waiting for the fix of https://issues.apache.org/jira/browse/CLOUDSTACK-1638 . We're using ovs/open flow to manipulate ingress/egress traffic to emulate the isolation PVLAN function on KVM and Xen. The details are in the FS. The core code change is minimal and there is no DB change, because we took advantage of broadcast domain to introduce pvlan:// broadcast URI to describe the primary and isolated PVLAN for the network. The code has passed the RAT, and no new dependency is added. How is the OpenFlow functionality controlled? Via libvirt? No, CS would execute the ovs-ofctl command. Libvirt(in kvm) would in charge of allocating vlan etc, but won't involve in openflow part. --Sheng I've added a new integration smoke test test_pvlan.py. Related unit tests are also added for NetUtils. I've done some basic regression tests, so far so good. Sangeetha already tested the functionality of Xen part, and it works. Integration test at: test/integration/smoke/test_pvlan.py If there is no objection, I would merge the branch in 48 hours. Thanks. --Sheng
Re: [MERGE]PVLAN branch to MASTER(v2)
On Tue, May 14, 2013 at 12:05:21PM -0700, Sheng Yang wrote: On Mon, May 13, 2013 at 6:58 PM, Chip Childers chipchild...@apache.orgwrote: On Mon, May 13, 2013 at 03:16:28PM -0700, Sheng Yang wrote: FS at: https://cwiki.apache.org/CLOUDSTACK/pvlan-for-isolation-within-a-vlan.html PVLAN branch has been under development for some time, and now the functionality works on KVM and Xen, would be followed by VMware soon VM live migration is not supported so far. Code is ready basically, but I am waiting for the fix of https://issues.apache.org/jira/browse/CLOUDSTACK-1638 . We're using ovs/open flow to manipulate ingress/egress traffic to emulate the isolation PVLAN function on KVM and Xen. The details are in the FS. The core code change is minimal and there is no DB change, because we took advantage of broadcast domain to introduce pvlan:// broadcast URI to describe the primary and isolated PVLAN for the network. The code has passed the RAT, and no new dependency is added. How is the OpenFlow functionality controlled? Via libvirt? No, CS would execute the ovs-ofctl command. Libvirt(in kvm) would in charge of allocating vlan etc, but won't involve in openflow part. --Sheng Got it... looked at the diff. Thanks Sheng.
RE: [ANNOUNCE] New committer: Devdeep Singh
Congratulations Devdeep -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Tuesday, May 14, 2013 8:17 AM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] New committer: Devdeep Singh The Project Management Committee (PMC) for Apache CloudStack has asked Devdeep Singh to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Devdeep! --Chip on behalf of the CloudStack PMC
Review Request: 4.1 zone wizard: disable SG option for advanced zones
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11164/ --- Review request for cloudstack. Description --- Disables 'security group' option under advanced zone wizard, step 1. This is because security groups aren't supported for advanced zones in 4.1. See https://issues.apache.org/jira/browse/CLOUDSTACK-2463 Diffs - ui/css/cloudstack3.css 7293624 Diff: https://reviews.apache.org/r/11164/diff/ Testing --- Thanks, Brian Federle
[ACS41] Next release candidate coming in a few hours!
Hi all, We have a clear bug list (blockers and critical) for 4.1.0. I'm going to cut a new release candidate tonight. If there are *any* outstanding issues known, now's the time to raise them. (I'm specifically looking for an ACK from jburwell here, since he mentioned a possible S3 feature issue. John, if you can please give me a heads up on where you stand in the next few hours, I'd appreciate it.) -chip
Re: [ACS41] Next release candidate coming in a few hours!
Chip, I am looking into the issue now. There is a failure when the S3 upload template command is issued. I working to determine whether or not the cause is environmental or code. Thanks, -John On May 14, 2013, at 4:56 PM, Chip Childers chip.child...@sungard.com wrote: Hi all, We have a clear bug list (blockers and critical) for 4.1.0. I'm going to cut a new release candidate tonight. If there are *any* outstanding issues known, now's the time to raise them. (I'm specifically looking for an ACK from jburwell here, since he mentioned a possible S3 feature issue. John, if you can please give me a heads up on where you stand in the next few hours, I'd appreciate it.) -chip
Re: [ACS41] Next release candidate coming in a few hours!
Chip, The source of the problem appears to be clock drift between the SSVM and S3 per following stack trace: 2013-05-14 06:51:55,400 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) Putting directory /mnt/SecStorage/93fd0cb0-033b-3248-bcd0-ef6d460635ef/template/tmpl/1/5 in S3 bucket jsb-cloudstack-templates. 2013-05-14 06:51:55,401 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) Creating S3 client with configuration: [protocol: https, connectionTimeOut: 5, maxErrorRetry: 3, socketTimeout: 5] 2013-05-14 06:51:55,403 DEBUG [storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-3:) Determining key using account id 1 and template id 5 2013-05-14 06:51:55,403 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) Putting file /mnt/SecStorage/93fd0cb0-033b-3248-bcd0-ef6d460635ef/template/tmpl/1/5/template.properties into bucket jsb-cloudstack-templates with key template/tmpl/1/5/template.properties. 2013-05-14 06:51:55,578 ERROR [storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-3:) Failed to upload template id 5 Status Code: 403, AWS Service: Amazon S3, AWS Request ID: 970A274E132A9ACB, AWS Error Code: RequestTimeTooSkewed, AWS Error Message: The difference between the request time and the current time is too large., S3 Extended Request ID: 9w8a6YBxTn+WlBg96s9stxWuuP8oQ7ksZtg6++wVRHJfE2qmucrilhoEJVetJui4 at com.amazonaws.http.AmazonHttpClient.handleErrorResponse(AmazonHttpClient.java:609) at com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:309) at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:164) at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:2863) at com.amazonaws.services.s3.AmazonS3Client.putObject(AmazonS3Client.java:1100) at com.amazonaws.services.s3.AmazonS3Client.putObject(AmazonS3Client.java:963) at com.cloud.utils.S3Utils.putDirectory(S3Utils.java:282) at com.cloud.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:414) at com.cloud.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:212) at com.cloud.agent.Agent.processRequest(Agent.java:525) at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852) at com.cloud.utils.nio.Task.run(Task.java:83) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) It does not appear that the System VM image has NTP nor does it seem like a valid assumption that an SSVM would have the connectivity to reach an NTP server. Therefore, do we have some other means to sync the clock on the SSVM (e.g. with the host through hypervisor extensions)? In my previous tests, the SSVM seemed to be syncing its time to the host which addressed the problem. Thanks, -John On May 14, 2013, at 4:58 PM, John Burwell jburw...@basho.com wrote: Chip, I am looking into the issue now. There is a failure when the S3 upload template command is issued. I working to determine whether or not the cause is environmental or code. Thanks, -John On May 14, 2013, at 4:56 PM, Chip Childers chip.child...@sungard.com wrote: Hi all, We have a clear bug list (blockers and critical) for 4.1.0. I'm going to cut a new release candidate tonight. If there are *any* outstanding issues known, now's the time to raise them. (I'm specifically looking for an ACK from jburwell here, since he mentioned a possible S3 feature issue. John, if you can please give me a heads up on where you stand in the next few hours, I'd appreciate it.) -chip
Re: Review Request: PVLAN provisioning support for vmware Distributed Virtual Switch deployments on cloudstack.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11019/ --- (Updated May 14, 2013, 10:35 p.m.) Review request for cloudstack, Chip Childers, Sheng Yang, Sateesh Chodapuneedi, Kelven Yang, and Animesh Chaturvedi. Changes --- Uploading fully tested vmware changes for pvlan support. Tests carried out: == Step 0. Provision PVLAN primary/isolated secondary VLAN on physical switch that the physical hosts will connect to, following appropriate manuals of the switch vendor. Step 1. Set the vmware.use.dvswitch global flag to true, restart mgmt server. Step 2. Create vmware cluster in vCenter. Enable cluster for vMotion. Step 3. Create vmware DVS on the vmware datacenter that the cluster belongs to. Step 4. Create cloudstack zone/vmware cluster on mgmt server. Step 5. Login as admin to the mgmt server, and under - Infrastructure - Zones view all - your zone - Physical network tab - Physical network name - Guest configure - Network tab - add Guest Network : create a pvlan enabled advanced shared network (you can use the Offering for shared networks network offering available in the drop down menu). Specify the primary (promiscuous vlan id) and the secondary isolated pvlan id. Specify valid routable IP gateway/ip range/netmask values. Step 6. Create a guest VM having the above network. It should come up with an eth0 interface plumbed with a DHCP IP picked from the ip address range provided in step 5. Ping the router VM's ip (on the same subnet) - it should go through. Step 7. Create another guest VM having the same network. It should also come up with an IP picked from the ip address range in step 5. This VM should be able to ping the router VM ip, but not the guest VM created in step 6. Step 8. Create an isolated network under Network - Add Guest network. Create a new guest VM having both this new isolated network and the shared pvlan network created above. The VM should come up fine with two eth interfaces, each having an ip range from the specified ranges. Same ping behavior must be observed for interfaces between guest VMs in the pvlan network. Step 9. vMotion the guest VMs from one physical host to another. The migration must be smooth, the VM up, with no change seen in network configuration or behavior. Description --- Please find attached the diffs for pvlan support for vmware DVSwitch deployments on cloudstack. You will find two diffs - the parent diff is Sateesh's fix for CLOUSTACK-2316 which is needed to be cherry-picked on the pvlan branch from the master. The other diff contains the changes for pvlan support. These diffs do not contain changes for pvlan provisioning on the Cisco Nexus 1000v distributed virtual switch. This addresses bug CLOUDSTACK-1456. Diffs (updated) - api/src/com/cloud/agent/api/PlugNicCommand.java b896e45 plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java 99ad1ca server/src/com/cloud/network/NetworkManagerImpl.java 7a09eb5 server/src/com/cloud/network/NetworkModelImpl.java bd62886 server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java bdfac06 server/src/com/cloud/vm/UserVmManagerImpl.java 683f0da server/src/com/cloud/vm/VirtualMachineManagerImpl.java b0d6378 vmware-base/src/com/cloud/hypervisor/vmware/mo/DistributedVirtualSwitchMO.java 247be2a vmware-base/src/com/cloud/hypervisor/vmware/mo/HypervisorHostHelper.java 7f323c5 Diff: https://reviews.apache.org/r/11019/diff/ Testing --- The code has been tested on the Vmware DVSwitch for advanced shared networks on vmware cluster deployments on cloudstack. Unit tests will be the same as those provided by Sheng as part of the overall PVLAN support for XenServer and KVM, and will exercise the vmware pvlan code path when user VMs are created with vNICs sitting on advanced shared networks that have the optional Private VLAN value set during their creation. VM live migration using vmware vMotion has also been tested with these changes on vmware and it works as expected. Further testing will be carried out and this review request will be updated accordingly. Thanks, Venkata Siva Vijayendra Bhamidipati
Re: [ACS41] Next release candidate coming in a few hours!
Chip, After some further discussion about this issue on IRC, Alex and I determined that system VM clock drift issue not only breaks S3, but has other significant impacts that merit it being a blocker for 4.1 (e.g. timestamps of files written by the SSVM being incorrect, log file correlation difficulties, sensitivity of other storage protocols to time sync, etc). Based on this conversation, I have opened CLOUDSTACK-2492 to capture the issue and track resolution. Thanks, -John On May 14, 2013, at 6:09 PM, John Burwell jburw...@basho.com wrote: Chip, The source of the problem appears to be clock drift between the SSVM and S3 per following stack trace: 2013-05-14 06:51:55,400 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) Putting directory /mnt/SecStorage/93fd0cb0-033b-3248-bcd0-ef6d460635ef/template/tmpl/1/5 in S3 bucket jsb-cloudstack-templates. 2013-05-14 06:51:55,401 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) Creating S3 client with configuration: [protocol: https, connectionTimeOut: 5, maxErrorRetry: 3, socketTimeout: 5] 2013-05-14 06:51:55,403 DEBUG [storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-3:) Determining key using account id 1 and template id 5 2013-05-14 06:51:55,403 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) Putting file /mnt/SecStorage/93fd0cb0-033b-3248-bcd0-ef6d460635ef/template/tmpl/1/5/template.properties into bucket jsb-cloudstack-templates with key template/tmpl/1/5/template.properties. 2013-05-14 06:51:55,578 ERROR [storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-3:) Failed to upload template id 5 Status Code: 403, AWS Service: Amazon S3, AWS Request ID: 970A274E132A9ACB, AWS Error Code: RequestTimeTooSkewed, AWS Error Message: The difference between the request time and the current time is too large., S3 Extended Request ID: 9w8a6YBxTn+WlBg96s9stxWuuP8oQ7ksZtg6++wVRHJfE2qmucrilhoEJVetJui4 at com.amazonaws.http.AmazonHttpClient.handleErrorResponse(AmazonHttpClient.java:609) at com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:309) at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:164) at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:2863) at com.amazonaws.services.s3.AmazonS3Client.putObject(AmazonS3Client.java:1100) at com.amazonaws.services.s3.AmazonS3Client.putObject(AmazonS3Client.java:963) at com.cloud.utils.S3Utils.putDirectory(S3Utils.java:282) at com.cloud.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:414) at com.cloud.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:212) at com.cloud.agent.Agent.processRequest(Agent.java:525) at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852) at com.cloud.utils.nio.Task.run(Task.java:83) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) It does not appear that the System VM image has NTP nor does it seem like a valid assumption that an SSVM would have the connectivity to reach an NTP server. Therefore, do we have some other means to sync the clock on the SSVM (e.g. with the host through hypervisor extensions)? In my previous tests, the SSVM seemed to be syncing its time to the host which addressed the problem. Thanks, -John On May 14, 2013, at 4:58 PM, John Burwell jburw...@basho.com wrote: Chip, I am looking into the issue now. There is a failure when the S3 upload template command is issued. I working to determine whether or not the cause is environmental or code. Thanks, -John On May 14, 2013, at 4:56 PM, Chip Childers chip.child...@sungard.com wrote: Hi all, We have a clear bug list (blockers and critical) for 4.1.0. I'm going to cut a new release candidate tonight. If there are *any* outstanding issues known, now's the time to raise them. (I'm specifically looking for an ACK from jburwell here, since he mentioned a possible S3 feature issue. John, if you can please give me a heads up on where you stand in the next few hours, I'd appreciate it.) -chip
Re: ssvm and system vm confusion
Chiradeep (others), Pedro Marques is working on a POC for an integration of Juniper's Contrail technology. He's Cc'ed on this thread. There are a number of questions related to system VM's below. Can someone please help answer them for him? On Tuesday, May 14, 2013, Pedro Marques wrote: Chip, Perhaps you can help me a bit... I'm trying to understand how to get the system vms working and i'm very confused... The cloudstack install instructions tell one to download a .vhd image that is installed as a template in the secondary storage. This template is instantiated when CS tries to start the SSVM. Cloudstack also has a systemvm.iso that is present in console-proxy/dist When CS initializes it goes through a process in which it tries to mount this iso and change the SSH keys in it. This process fails since the scripts that it uses assume sudo which requires console access. How is the systemvm.iso image supposed to actually get launched on a server ? i'm not seen any way in which this image gets copied... and there is no way to create a Xen VM from this (non-bootable iso), correct ? Given that the SSVM is a .vhd image that is downloaded from citrix how is CS expected to be able to place its keys in it and be able to login ? The tools/appliance scripts don't work for me. I managed to work around an auth failure... the definitions/systemvmtemplate scripts assume user root with password password but preseed.cfg doesn't create a root account... and would use vagrant as the password... But after this auth failure i see that the post install script does the following... ++ chroot . apt-get --no-install-recommends -q -y --force-yes install rsyslog logrotate cron chkconfig insserv net-tools ifupdown vim-tiny netbase iptables openssh-server grub-legacy e2fsprogs dhcp3-client dnsmasq tcpdump socat wget python bzip2 sed gawk diff grep gzip less tar telnet ftp rsync traceroute psmisc lsof procps monit inetutils-ping iputils-arping httping dnsutils zip unzip ethtool uuid file iproute acpid iptables-persistent virt-what sudo chroot: failed to run command `apt-get': No such file or directory ERROR: exit code 127 Error executing command ./postinstall.sh : Exitcode was not what we expected Exitcode was not what we expected I'm assuming that . is supposed to be /root on the VM... what is this attempting to do ? There is no apt-get in /root/usr/bin so the command will fail... what is the intent here... Saving this VM in this state, i can start it in the compute node, but it comes up with a single interface (eth0)... I'm trying to figure out how it is possible to build an SSVM that CS would be able to log into... but i'm confused... Pedro.
Re: [ACS41] Next release candidate coming in a few hours!
On Tuesday, May 14, 2013, John Burwell wrote:
Chip,
After some further discussion about this issue on IRC, Alex and I
determined that system VM clock drift issue not only breaks S3, but has
other significant impacts that merit it being a blocker for 4.1 (e.g.
timestamps of files written by the SSVM being incorrect, log file
correlation difficulties, sensitivity of other storage protocols to time
sync, etc). Based on this conversation, I have opened
CLOUDSTACK-2492https://issues.apache.org/jira/browse/CLOUDSTACK-2492 to
capture the issue and track resolution.
Thanks,
-John
Well shoot. Issuing a new system VM is going to require a bunch of testing
if it's not done as a hand rolled edit of the existing system VMs.
Who can take this?
On May 14, 2013, at 6:09 PM, John Burwell
jburw...@basho.comjavascript:_e({}, 'cvml', 'jburw...@basho.com');
wrote:
Chip,
The source of the problem appears to be clock drift between the SSVM and
S3 per following stack trace:
2013-05-14 06:51:55,400 DEBUG [cloud.utils.S3Utils]
(agentRequest-Handler-3:) Putting directory
/mnt/SecStorage/93fd0cb0-033b-3248-bcd0-ef6d460635ef/template/tmpl/1/5 in
S3 bucket jsb-cloudstack-templates.
2013-05-14 06:51:55,401 DEBUG [cloud.utils.S3Utils]
(agentRequest-Handler-3:) Creating S3 client with configuration: [protocol:
https, connectionTimeOut: 5, maxErrorRetry: 3, socketTimeout: 5]
2013-05-14 06:51:55,403 DEBUG
[storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-3:)
Determining key using account id 1 and template id 5
2013-05-14 06:51:55,403 DEBUG [cloud.utils.S3Utils]
(agentRequest-Handler-3:) Putting file
/mnt/SecStorage/93fd0cb0-033b-3248-bcd0-ef6d460635ef/template/tmpl/1/5/template.properties
into bucket jsb-cloudstack-templates with key
template/tmpl/1/5/template.properties.
2013-05-14 06:51:55,578 ERROR
[storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-3:)
Failed to upload template id 5
Status Code: 403, AWS Service: Amazon S3, AWS Request ID:
970A274E132A9ACB, AWS Error Code: RequestTimeTooSkewed, AWS Error Message:
The difference between the request time and the current time is too large.,
S3 Extended Request ID:
9w8a6YBxTn+WlBg96s9stxWuuP8oQ7ksZtg6++wVRHJfE2qmucrilhoEJVetJui4
at
com.amazonaws.http.AmazonHttpClient.handleErrorResponse(AmazonHttpClient.java:609)
at
com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:309)
at
com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:164)
at
com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:2863)
at
com.amazonaws.services.s3.AmazonS3Client.putObject(AmazonS3Client.java:1100)
at
com.amazonaws.services.s3.AmazonS3Client.putObject(AmazonS3Client.java:963)
at com.cloud.utils.S3Utils.putDirectory(S3Utils.java:282)
at
com.cloud.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:414)
at
com.cloud.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:212)
at com.cloud.agent.Agent.processRequest(Agent.java:525)
at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852)
at com.cloud.utils.nio.Task.run(Task.java:83)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
It does not appear that the System VM image has NTP nor does it seem like
a valid assumption that an SSVM would have the connectivity to reach an NTP
server. Therefore, do we have some other means to sync the clock on the
SSVM (e.g. with the host through hypervisor extensions)? In my previous
tests, the SSVM seemed to be syncing its time to the host which addressed
the problem.
Thanks,
-John
On May 14, 2013, at 4:58 PM, John Burwell
jburw...@basho.comjavascript:_e({}, 'cvml', 'jburw...@basho.com');
wrote:
Chip,
I am looking into the issue now. There is a failure when the S3 upload
template command is issued. I working to determine whether or not the
cause is environmental or code.
Thanks,
-John
On May 14, 2013, at 4:56 PM, Chip Childers
chip.child...@sungard.comjavascript:_e({}, 'cvml',
'chip.child...@sungard.com');
wrote:
Hi all,
We have a clear bug list (blockers and critical) for 4.1.0. I'm going
to cut a new release candidate tonight.
If there are *any* outstanding issues known, now's the time to raise
them.
(I'm specifically looking for an ACK from jburwell here, since he
mentioned a possible S3 feature issue. John, if you can please give me
a heads up on where you stand in the next few hours, I'd appreciate it.)
-chip
Re: [jira] [Updated] (CLOUDSTACK-2492) System VM Clock Drift
for KVM, we could potentially force the kvmclock clocksource on system vms via the libvirt XML. It requires that all system vms be linux though, and I'd have to look into whether the old system vm supports it. If so, should be an easy fix. On Tue, May 14, 2013 at 5:20 PM, John Burwell (JIRA) j...@apache.orgwrote: [ https://issues.apache.org/jira/browse/CLOUDSTACK-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] John Burwell updated CLOUDSTACK-2492: - Labels: documentaion (was: ) System VM Clock Drift - Key: CLOUDSTACK-2492 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2492 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: ISO Affects Versions: 4.1.0 Environment: devcloud/Xen Reporter: John Burwell Priority: Blocker Labels: documentaion Testing of S3-backed Secondary Storage has revealed that the SSVM (and likely all other system VMs) have no provision for clock synchronization (e.g. NTP to dom0 for Xen, vmware-tools for VMWare, etc). In particular, the S3 protocol is sensitive to drift between clients and S3. As an example, the following is the stack trace caused by clock drift S3: 2013-05-14 06:51:55,400 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) Putting directory /mnt/SecStorage/93fd0cb0-033b-3248-bcd0-ef6d460635ef/template/tmpl/1/5 in S3 bucket jsb-cloudstack-templates. 2013-05-14 06:51:55,401 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) Creating S3 client with configuration: [protocol: https, connectionTimeOut: 5, maxErrorRetry: 3, socketTimeout: 5] 2013-05-14 06:51:55,403 DEBUG [storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-3:) Determining key using account id 1 and template id 5 2013-05-14 06:51:55,403 DEBUG [cloud.utils.S3Utils] (agentRequest-Handler-3:) Putting file /mnt/SecStorage/93fd0cb0-033b-3248-bcd0-ef6d460635ef/template/tmpl/1/5/template.properties into bucket jsb-cloudstack-templates with key template/tmpl/1/5/template.properties. 2013-05-14 06:51:55,578 ERROR [storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-3:) Failed to upload template id 5 Status Code: 403, AWS Service: Amazon S3, AWS Request ID: 970A274E132A9ACB, AWS Error Code: RequestTimeTooSkewed, AWS Error Message: The difference between the request time and the current time is too large., S3 Extended Request ID: 9w8a6YBxTn+WlBg96s9stxWuuP8oQ7ksZtg6++wVRHJfE2qmucrilhoEJVetJui4 at com.amazonaws.http.AmazonHttpClient.handleErrorResponse(AmazonHttpClient.java:609) at com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:309) at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:164) at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:2863) at com.amazonaws.services.s3.AmazonS3Client.putObject(AmazonS3Client.java:1100) at com.amazonaws.services.s3.AmazonS3Client.putObject(AmazonS3Client.java:963) at com.cloud.utils.S3Utils.putDirectory(S3Utils.java:282) at com.cloud.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:414) at com.cloud.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:212) at com.cloud.agent.Agent.processRequest(Agent.java:525) at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852) at com.cloud.utils.nio.Task.run(Task.java:83) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) In addition to impacting S3, this clock drift also makes log correlation between the management server and system VMs very difficult, if not, impossible. Finally, there are suspicions that the clock drift could also impact operation of console proxy and virtual router VMs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [ANNOUNCE] New committer: Devdeep Singh
Well deservedŠcongrats :) On 14/05/13 8:48 PM, Chip Childers chip.child...@sungard.com wrote: The Project Management Committee (PMC) for Apache CloudStack has asked Devdeep Singh to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Devdeep! --Chip on behalf of the CloudStack PMC
RE: [ANNOUNCE] New committer: Devdeep Singh
Hearty Congratulations Dev! On 14/05/13 8:48 PM, Chip Childers chip.child...@sungard.com wrote: The Project Management Committee (PMC) for Apache CloudStack has asked Devdeep Singh to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Devdeep! --Chip on behalf of the CloudStack PMC
RE: [ACS42][QA] Test Plan for Support of Netscaler as external LB in VPC
Regarding upgrade path I had updated in the FS. -Original Message- From: Sowmya Krishnan Sent: Thursday, May 9, 2013 4:38 PM To: Rajesh Battala; dev@cloudstack.apache.org Subject: RE: [ACS42][QA] Test Plan for Support of Netscaler as external LB in VPC -Original Message- From: Rajesh Battala Sent: Thursday, May 09, 2013 3:15 PM To: Sowmya Krishnan; dev@cloudstack.apache.org Subject: RE: [ACS42][QA] Test Plan for Support of Netscaler as external LB in VPC There are two things, upgrading VPC, and upgrading VPC network offering. Upgrading VPC is not supported. Ok. I am talking about updateVPCOffering. Correct me if I am wrong here: we couldn't change VPC offering till now since we had only one offering for VPC: Default Offering. Now that we have a new offering (Default Offering with NS), shouldn't we allow updating the VPC offering? Otherwise, I don't see how we can upgrade the network tier offering to use External device without updating the VPC to use NS? Upgrading VPC networking offering (only valid scenario is LB vpc to NS Lb). upgrading the network where External device is involved changing the cidr. This is the network tier offering: updateNetwork. Are you saying this valid scenario is supported? Example: updateNetwork from offering which supports VPCVR as LB to offering which support NS as LB Will update in FS. Thanks. -Original Message- From: Sowmya Krishnan Sent: Thursday, May 9, 2013 2:38 PM To: Rajesh Battala; dev@cloudstack.apache.org Subject: RE: [ACS42][QA] Test Plan for Support of Netscaler as external LB in VPC Thanks Rajesh. Could you please let me know the technical reason why we are not supporting Upgrade of VPC network offering or network tier LB? This limitation needs to be documented. Also, could you please update the same in FS too. -Original Message- From: Rajesh Battala Sent: Thursday, May 09, 2013 1:54 PM To: Sowmya Krishnan; dev@cloudstack.apache.org Subject: RE: [ACS42][QA] Test Plan for Support of Netscaler as external LB in VPC Please see my comments in-line. Please let me know your comments. -Original Message- From: Sowmya Krishnan Sent: Tuesday, May 7, 2013 3:34 PM To: dev@cloudstack.apache.org Cc: Rajesh Battala Subject: [ACS42][QA] Test Plan for Support of Netscaler as external LB in VPC I am planning to take up test execution for the feature : Support for Netscaler as External Load Balancer in VPC I've written some test cases for the same. Please review and let me know if any comments. Here are Test cases: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Support+for+N et s caler+as+External+Load+Balancer+in+VPC+Tests Ref FS for the feature is here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Support+of+Ne ts c aler+as+External+LoadBalancing+Provider+in+VPC [Rajesh Battala] 48. Create VPC with shared NS : It should fail only when tier is created and implemented with NS as LB ( when NS of type only shared is available it should fail) not while creating VPC. Tests cases that should/can be include : 1. As External Devices (Netscaler) is involved while tier creation, cidr should be subset from the super cidr ( new cidr out of super cidr should not be generated) 2. When tier is created with LB as Netscaler ( and network is implemented) the VpcVR should have a new nic attached and the ip of the nic should be the gateway ip specified while creating the tier. 3. when tier is created with LB as NS, when a dedicated NS is available after tier got implemented NS state should be in allocated. 4. when the tier is delete where NS is dedicate, NS allocation state should be moved to free pool. 5. Deletion of NS device should fail if the device is in active/used in the tier. There are few questions on the FS as I was writing the tests. Rajesh, could you please let me know your response for these. I'll update the Test plan accordingly. 1. I am assuming upgrade of VPC offering from Default offering to Default Offering with NS is allowed. If not, need to update this in the FS if there are any limitations on this front. [Rajesh Battala] Upgrading not supported currently. We can create an enhancement to track it. 2. On the same lines, upgrade of network offering of the network tier is also possible I assume . (For example, from LB provided by VpcVirtualRouter to LB provided by Netscaler) [Rajesh Battala] Upgrading of LB is possible but not supported currently. 3. Also on the UI front, currently while creating network offering for the tier, if we choose VPC, Netscaler as service provider for LB is disabled. We
RE: Firewall rule question
For the createFirewallRule and createEgressFirewallRule APIs the port parameters are optional. If you don't specify the port range for the prototocol (TCP) it allows all the tcp traffic. Ingress: 1. First firewall rules filters traffic then PF/Static NAT will NAT to the specific VM. If you specify tcp with out ports all tcp traffic on IP is allowed then PF/Static NAT rule (PF ports) decides to which VM the traffic should be NATed. Egress: Traffic from guest network to public network is filtered by egress. If you specify the tcp with out ports all egress tcp traffic is allowed. Thanks, Jayapal -Original Message- From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of Will Stevens Sent: Wednesday, 15 May 2013 12:19 AM To: dev@cloudstack.apache.org; aemne...@gmail.com Subject: Re: Firewall rule question Ya, I am not sure. I am working off a master branch from about 2-3 weeks ago. I was kind of expecting it to error and it didn't, so it was not clear how that case would behave. I am currently developing an integration with the Palo Alto firewall and they don't support specifying a protocol like TCP without any port information. I still have to finalize the logic associated with that edge case, so I wanted to understand what the expected behaviour was from that config. On Tue, May 14, 2013 at 2:41 PM, Ahmad Emneina aemne...@gmail.com wrote: I'm hoping thats not the default behavior, and nothing happens on the firewall. I guess the fact that empty values entered returns success is a bug? On Tue, May 14, 2013 at 8:00 AM, Will Stevens wstev...@cloudops.com wrote: This applies to both Egress firewall rules as well as IP specific firewall rules. If you specify TCP but do not specify any port details, it saves fine. I am wondering what this config implies. Does this mean that all TCP traffic is allowed? Thanks, Will
Re: Firewall rule question
understood. I assume this is the documented (in a FS or some such design doc) behavior, correct? Thanks for the prompt reply Jaypal! On Tue, May 14, 2013 at 9:58 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: For the createFirewallRule and createEgressFirewallRule APIs the port parameters are optional. If you don't specify the port range for the prototocol (TCP) it allows all the tcp traffic. Ingress: 1. First firewall rules filters traffic then PF/Static NAT will NAT to the specific VM. If you specify tcp with out ports all tcp traffic on IP is allowed then PF/Static NAT rule (PF ports) decides to which VM the traffic should be NATed. Egress: Traffic from guest network to public network is filtered by egress. If you specify the tcp with out ports all egress tcp traffic is allowed. Thanks, Jayapal -Original Message- From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of Will Stevens Sent: Wednesday, 15 May 2013 12:19 AM To: dev@cloudstack.apache.org; aemne...@gmail.com Subject: Re: Firewall rule question Ya, I am not sure. I am working off a master branch from about 2-3 weeks ago. I was kind of expecting it to error and it didn't, so it was not clear how that case would behave. I am currently developing an integration with the Palo Alto firewall and they don't support specifying a protocol like TCP without any port information. I still have to finalize the logic associated with that edge case, so I wanted to understand what the expected behaviour was from that config. On Tue, May 14, 2013 at 2:41 PM, Ahmad Emneina aemne...@gmail.com wrote: I'm hoping thats not the default behavior, and nothing happens on the firewall. I guess the fact that empty values entered returns success is a bug? On Tue, May 14, 2013 at 8:00 AM, Will Stevens wstev...@cloudops.com wrote: This applies to both Egress firewall rules as well as IP specific firewall rules. If you specify TCP but do not specify any port details, it saves fine. I am wondering what this config implies. Does this mean that all TCP traffic is allowed? Thanks, Will
RE: Firewall rule question
-Original Message- From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] Sent: Wednesday, May 15, 2013 10:29 AM To: dev@cloudstack.apache.org; aemne...@gmail.com Subject: RE: Firewall rule question For the createFirewallRule and createEgressFirewallRule APIs the port parameters are optional. If you don't specify the port range for the prototocol (TCP) it allows all the tcp traffic. Ingress: 1. First firewall rules filters traffic then PF/Static NAT will NAT to the specific VM. If you specify tcp with out ports all tcp traffic on IP is allowed then PF/Static NAT rule (PF ports) decides to which VM the traffic should be NATed. Egress: Traffic from guest network to public network is filtered by egress. If you specify the tcp with out ports all egress tcp traffic is allowed. In case of egress even the cidr is optional. If nothing is specified it defaults to the guest network cidr. Thanks, Jayapal -Original Message- From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of Will Stevens Sent: Wednesday, 15 May 2013 12:19 AM To: dev@cloudstack.apache.org; aemne...@gmail.com Subject: Re: Firewall rule question Ya, I am not sure. I am working off a master branch from about 2-3 weeks ago. I was kind of expecting it to error and it didn't, so it was not clear how that case would behave. I am currently developing an integration with the Palo Alto firewall and they don't support specifying a protocol like TCP without any port information. I still have to finalize the logic associated with that edge case, so I wanted to understand what the expected behaviour was from that config. On Tue, May 14, 2013 at 2:41 PM, Ahmad Emneina aemne...@gmail.com wrote: I'm hoping thats not the default behavior, and nothing happens on the firewall. I guess the fact that empty values entered returns success is a bug? On Tue, May 14, 2013 at 8:00 AM, Will Stevens wstev...@cloudops.com wrote: This applies to both Egress firewall rules as well as IP specific firewall rules. If you specify TCP but do not specify any port details, it saves fine. I am wondering what this config implies. Does this mean that all TCP traffic is allowed? Thanks, Will
RE: [ANNOUNCE] New committer: Devdeep Singh
Congratulations Devdeep! -Original Message- From: Sateesh Chodapuneedi [mailto:sateesh.chodapune...@citrix.com] Sent: Wednesday, 15 May 2013 9:59 AM To: dev@cloudstack.apache.org Subject: RE: [ANNOUNCE] New committer: Devdeep Singh Hearty Congratulations Dev! On 14/05/13 8:48 PM, Chip Childers chip.child...@sungard.com wrote: The Project Management Committee (PMC) for Apache CloudStack has asked Devdeep Singh to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Devdeep! --Chip on behalf of the CloudStack PMC
RE: Firewall rule question
-Original Message- From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of Will Stevens Sent: Wednesday, May 15, 2013 12:19 AM To: dev@cloudstack.apache.org; aemne...@gmail.com Subject: Re: Firewall rule question Ya, I am not sure. I am working off a master branch from about 2-3 weeks ago. I was kind of expecting it to error and it didn't, so it was not clear how that case would behave. I am currently developing an integration with the Palo Alto firewall and they don't support specifying a protocol like TCP without any port information. I still have to finalize the logic associated with that edge case, so I wanted to understand what the expected behaviour was from that config. I recently did the Cisco ASA firewall integration and there it is allowed to create a firewall rule with TCP without specifying any port information. I think you can either do one of the following: - Block it if Palo Alto firewall doesn't allow creation of TCP rule without port information OR - Create a rule with all possible port ranges (min and max port values) On Tue, May 14, 2013 at 2:41 PM, Ahmad Emneina aemne...@gmail.com wrote: I'm hoping thats not the default behavior, and nothing happens on the firewall. I guess the fact that empty values entered returns success is a bug? On Tue, May 14, 2013 at 8:00 AM, Will Stevens wstev...@cloudops.com wrote: This applies to both Egress firewall rules as well as IP specific firewall rules. If you specify TCP but do not specify any port details, it saves fine. I am wondering what this config implies. Does this mean that all TCP traffic is allowed? Thanks, Will
Re: [ANNOUNCE] New committer: Devdeep Singh
Congrats Devdeep. On 14-May-2013, at 8:46 PM, Chip Childers chip.child...@sungard.com wrote: The Project Management Committee (PMC) for Apache CloudStack has asked Devdeep Singh to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Devdeep! --Chip on behalf of the CloudStack PMC
RE: [ANNOUNCE] New committer: Devdeep Singh
Congrats Devdeep! -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Tuesday, May 14, 2013 8:48 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] New committer: Devdeep Singh The Project Management Committee (PMC) for Apache CloudStack has asked Devdeep Singh to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Devdeep! --Chip on behalf of the CloudStack PMC
