Re: [DISCUSS] Policy blocker?
On Feb 21, 2014, at 7:37 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Friday, February 21, 2014 4:13 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? LEGAL - when I talk about legal problems below I refer to liability incurred by individuals in the project, especially the release manager, [Animesh] Can you clarify 'especially the release manager' part? Release manager is just like any other volunteer and does not have any special privileges. The community VOTEs on the release. Sure, it isn't about privilege, it's about liability. So the foundation covers (and has insurance for) actions taken on behalf of the Foundation. If process is followed (including getting the votes) releasing software is effectively a function of the Foundation - and thus it bears liability. The foundation needs to ensure that the release is a 'authorized business decision' on behalf of the Foundation (which is why the Board has to ACK PMC additions, etc.). Hence all the process and policy. Publishing software however, if really done by the release manager. And if release process isn't followed, it's no longer a function of the foundation - and software is effectively released by the RM, and thus he is individually liable. [Animesh] How do you define the release process being followed or not? Isn't Voting on a release the process and PMC and everyone voting responsible for it. Release Manager is a facilitator. Without the protection why would anyone want to incur liability as a release manager? In the links that you sent I have not seen specific reference to Release Manager being liable. Sadly this isn't theoretical, and is one of the reasons that the foundation exists. [Animesh] What does foundation provide in that case? I read David note as saying that if we follow the release process properly -calling for votes, respecting bylaws timeframe, tallying…etc- then the ASF is liable for what's in the release. But if we were to not follow due process then the RM would be liable. In our case we follow process, so the Foundation is liable. http://www.apache.org/dev/release.html#why https://www.apache.org/foundation/faq.html#why --David
Re: [DISCUSS] Policy blocker?
On Sat, Feb 22, 2014 at 3:07 AM, Sebastien Goasguen run...@gmail.com wrote: On Feb 21, 2014, at 7:37 PM, Animesh Chaturvedi animesh.chaturv...@citrix.com wrote: -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Friday, February 21, 2014 4:13 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? LEGAL - when I talk about legal problems below I refer to liability incurred by individuals in the project, especially the release manager, [Animesh] Can you clarify 'especially the release manager' part? Release manager is just like any other volunteer and does not have any special privileges. The community VOTEs on the release. Sure, it isn't about privilege, it's about liability. So the foundation covers (and has insurance for) actions taken on behalf of the Foundation. If process is followed (including getting the votes) releasing software is effectively a function of the Foundation - and thus it bears liability. The foundation needs to ensure that the release is a 'authorized business decision' on behalf of the Foundation (which is why the Board has to ACK PMC additions, etc.). Hence all the process and policy. Publishing software however, if really done by the release manager. And if release process isn't followed, it's no longer a function of the foundation - and software is effectively released by the RM, and thus he is individually liable. [Animesh] How do you define the release process being followed or not? Isn't Voting on a release the process and PMC and everyone voting responsible for it. Release Manager is a facilitator. Without the protection why would anyone want to incur liability as a release manager? In the links that you sent I have not seen specific reference to Release Manager being liable. Sadly this isn't theoretical, and is one of the reasons that the foundation exists. [Animesh] What does foundation provide in that case? I read David note as saying that if we follow the release process properly -calling for votes, respecting bylaws timeframe, tallying...etc- then the ASF is liable for what's in the release. But if we were to not follow due process then the RM would be liable. In our case we follow process, so the Foundation is liable. Yes, if I wasn't clear - what Sebastien said was my intent. --David
Re: Review Request 18358: NetUtils unit testing
On Feb. 21, 2014, 6:54 p.m., Laszlo Hornyak wrote: Hi Miguel, I started working on verification and I ran into some dependency problem. hamcrest-library is needed as dependency and junit 4.10 needs to be upgraded to 4.11 Hi Laszio, Good catch! I did not run the tets from maven, only from Eclipse and there I had no dependency problem. I applied your patch on my code base and it fixes the errors for me. In addition to that I've added a variable for the version of hamcrest, just like it is done for the other dependencies. I will update the patch with my changes and yours together. Please let me know if that is not the best way to go and I'll make a new patch with just my changes. - Miguel --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18358/#review35179 --- On Feb. 21, 2014, 4:43 p.m., Miguel Ferreira wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18358/ --- (Updated Feb. 21, 2014, 4:43 p.m.) Review request for cloudstack, daan Hoogland and Hugo Trippaers. Repository: cloudstack-git Description --- - Refactor tests: - Upgrade tests to use jUnit4 - Break big tests in small unit tests - Replace assertTrue/False with complex conditions by assertThat with specific matchers - Remove dead code: - Private static method never called locally - Add test for method that validates CIDRs Diffs - utils/src/com/cloud/utils/net/NetUtils.java c22e39a utils/test/com/cloud/utils/net/NetUtilsTest.java d3e283c Diff: https://reviews.apache.org/r/18358/diff/ Testing --- Ran all the tests in the test class before and after refactoring. Thanks, Miguel Ferreira
Re: Review Request 18358: NetUtils unit testing
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18358/ --- (Updated Feb. 22, 2014, 1:41 p.m.) Review request for cloudstack, daan Hoogland and Hugo Trippaers. Changes --- Add hamcrest dependency to pom (contribution of Laszio Hornyak) Repository: cloudstack-git Description --- - Refactor tests: - Upgrade tests to use jUnit4 - Break big tests in small unit tests - Replace assertTrue/False with complex conditions by assertThat with specific matchers - Remove dead code: - Private static method never called locally - Add test for method that validates CIDRs Diffs (updated) - pom.xml 1e9e8d8 utils/src/com/cloud/utils/net/NetUtils.java c22e39a utils/test/com/cloud/utils/net/NetUtilsTest.java d3e283c Diff: https://reviews.apache.org/r/18358/diff/ Testing --- Ran all the tests in the test class before and after refactoring. Thanks, Miguel Ferreira
Re: Review Request 15932: Add support for Primary Storage on Gluster using the libvirt backend
On Feb. 19, 2014, 2:35 p.m., Wido den Hollander wrote: It seems good to me. Applies cleanly to master and builds just fine. Code-wise it's simple but effective, should allow us to support Gluster. Wido den Hollander wrote: I just merged it into master and pushed. So gluster is in master right now! Niels, can I ask you to test it all again? Just to make sure the code all works like you intended. Thanks Wido! This seems to be working OK for me. Note that the UI modification (https://reviews.apache.org/r/15933/) have not been reviewed/merged yet. Without these, it's rather difficult for users to configure Primary Storage on Gluster. Also, I've got asked about the dependencies and configuration. I'll add that here for now, and I'll try figure out how to get it added to the documentation: In /etc/glusterfs/glusterd.vol, allow unprivileged ports to contact the 'management' volume to get the volume configuration: option rpc-auth-allow-insecure on After changing the glusterd.vol file, restart the glusterd service to apply the changes. Per volume, allow unprivileged ports to access the brick processes (glusterfsd): # gluster volume set volname server.allow-insecure on # gluster volume stop volume # gluster volume start volume Per volume make sure that the kvm user (uid=36) and kvm group (gid=36) can access the images on the volume: # gluster volume set volname storage.owner-uid 36 # gluster volume set volname storage.owner-gid 36 Other dependencies: * libvirt version 1.0.1 (gluster protocol/network disk support) * qemu version 1.3 (gluster block backend support) Note that RHEL-6.5 and derived distributions contain backports that add sufficient functionality too. - Niels --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15932/#review34859 --- On Feb. 19, 2014, 9:24 a.m., Niels de Vos wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/15932/ --- (Updated Feb. 19, 2014, 9:24 a.m.) Review request for cloudstack. Repository: cloudstack-git Description --- The support for Gluster as Primary Storage is mostly based on the implementation for NFS. Like NFS, libvirt can address a Gluster environment through the 'netfs' pool-type. Diffs - api/src/com/cloud/storage/Storage.java ff83dfc plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java d63b643 plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtStoragePoolDef.java dbe5d4b plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtStoragePoolXMLParser.java a6186f6 plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java ff75d61 plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStorageProcessor.java 8cdecd8 plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java a5f33eb plugins/storage/volume/default/src/org/apache/cloudstack/storage/datastore/lifecycle/CloudStackPrimaryDataStoreLifeCycleImpl.java b90d5fc Diff: https://reviews.apache.org/r/15932/diff/ Testing --- See http://blog.nixpanic.net/2013/12/using-gluster-as-primary-storage-in.html Thanks, Niels de Vos
Re: Review Request 18310: dnsmasq fix for bridged networks
Hi Sheng, First of thank you for reviewing my first attempt to contribu Sent from my iPhone On 21 feb. 2014, at 20:00, Sheng Yang sh...@yasker.orgmailto:sh...@yasker.org wrote: Hi Joris, This patch hasn't been applied yet, sorry for my second thought. Could you comment on it? --Sheng On Thu, Feb 20, 2014 at 10:29 AM, Sheng Yang sh...@yasker.orgmailto:sh...@yasker.org wrote: This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18310/ On February 20th, 2014, 6:17 p.m. UTC, Sheng Yang wrote: Looks good to me. Also I've confirmed that even with this option, the MAC would show in dnsmasq.log, which is necessary for debug. Applied to MASTER. Thanks! On February 20th, 2014, 6:28 p.m. UTC, Sheng Yang wrote: One moment, on a second thought, even with current setup, dnsmasq won't hand out IP to unknown host. So why this option is needed? And the log would show DHCPDISCOVER(eth0) 02:01:3a:d9:00:02 no address available instead of DHCPDISCOVER(eth0) 02:01:3a:d9:00:02 ignored with the option. Is there anything I missed? And the patch hasn't been applied yet... - Sheng On February 20th, 2014, 2:01 p.m. UTC, Joris van Lieshout wrote: Review request for cloudstack, daan Hoogland, Hugo Trippaers, and Sheng Yang. By Joris van Lieshout. Updated Feb. 20, 2014, 2:01 p.m. Repository: cloudstack-git Description When a ACS network is bridged to another non-ACS network (for instance using a NSX Bridge) this will prevent dnsmasq from responding to requests from the other network that have traversed the bridge. Testing We have been running this fix on our own version of the 4.2 and 3.0 SVM for a couple months with success. Diffs * systemvm/patches/debian/config/etc/dnsmasq.conf.tmpl (07c5902) View Diffhttps://reviews.apache.org/r/18310/diff/
Re: Review Request 18310: dnsmasq fix for bridged networks
Hi Sheng, First of thanks you for reviewing my first attempt to contribute :) and sorry for my late response. I want to gadder a bit more info because I've seen it hand out adresses. Besides that this setting should at least provide an extra failsafe. Regards, Joris Sent from my iPhone On 21 feb. 2014, at 20:00, Sheng Yang sh...@yasker.orgmailto:sh...@yasker.org wrote: Hi Joris, This patch hasn't been applied yet, sorry for my second thought. Could you comment on it? --Sheng On Thu, Feb 20, 2014 at 10:29 AM, Sheng Yang sh...@yasker.orgmailto:sh...@yasker.org wrote: This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18310/ On February 20th, 2014, 6:17 p.m. UTC, Sheng Yang wrote: Looks good to me. Also I've confirmed that even with this option, the MAC would show in dnsmasq.log, which is necessary for debug. Applied to MASTER. Thanks! On February 20th, 2014, 6:28 p.m. UTC, Sheng Yang wrote: One moment, on a second thought, even with current setup, dnsmasq won't hand out IP to unknown host. So why this option is needed? And the log would show DHCPDISCOVER(eth0) 02:01:3a:d9:00:02 no address available instead of DHCPDISCOVER(eth0) 02:01:3a:d9:00:02 ignored with the option. Is there anything I missed? And the patch hasn't been applied yet... - Sheng On February 20th, 2014, 2:01 p.m. UTC, Joris van Lieshout wrote: Review request for cloudstack, daan Hoogland, Hugo Trippaers, and Sheng Yang. By Joris van Lieshout. Updated Feb. 20, 2014, 2:01 p.m. Repository: cloudstack-git Description When a ACS network is bridged to another non-ACS network (for instance using a NSX Bridge) this will prevent dnsmasq from responding to requests from the other network that have traversed the bridge. Testing We have been running this fix on our own version of the 4.2 and 3.0 SVM for a couple months with success. Diffs * systemvm/patches/debian/config/etc/dnsmasq.conf.tmpl (07c5902) View Diffhttps://reviews.apache.org/r/18310/diff/
Re: [DISCUSS] Policy blocker?
Hi folks: I think this issue is resolved in the 4.3 branch. The default build system no longer seems to grab the mysql jar, and I've adjusted tomcat to load the mysql jar from the system library. Commit 0c2ad0338e34f6117cecc24ec00c7746dd481465 should have the necessary changes. I did some quick testing, and this seems to work, but obviously it needs more eyes and testing. --David On Thu, Feb 20, 2014 at 8:37 AM, David Nalley da...@gnsa.us wrote: Hi folks, I cringe to raise this issue. After 6 RCs I am sure we are all feeling a little bit of release vote fatigue. Especially Animesh. I apologize in advance; in all other respects I am ready to give a +1 to RC6. I've been playing with 4.3.0-rc6 for a couple of days now. I attempted to build some RPMs and had problems with dependency resolution in maven. This led me to looking at a number of different poms, and I noticed mysql-connector-java is listed as a runtime dependency. For our end users, this really isn't necessary - the debs and rpms specify a requirement (effectively a system requirement in the terms of policy) for mysql-connector-java. We don't need it to build the software (at least not in any location I've seen) - just when running. (And thus its a system dependency, much like MySQL is.) mysql-connector-java is GPLv2; which is Cat X. By including it as a dependency in the pom it automatically gets downloaded. The 3rd Party software policy has this line in it: YOU MUST NOT distribute build scripts or documentation within an Apache product with the purpose of causing the default/standard build of an Apache product to include any part of aprohibited work. We've released software with this dependency previously. Is this a blocker for 4.3 or do we fix going forward? (If we hadn't already shipped releases with this problem I'd lean a bit more towards it being a blocker - but its more murky now.) Thoughts, comments, flames? --David [1] https://www.apache.org/legal/3party.html
RE: [DISCUSS] Policy blocker?
Hi David, One doubt, while building cloudstack we are using mysql-connector-java version 5.1.29; is it not mandatory we should supposed to use same version of mysql-connector during run time? Regards, Rayees -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: Saturday, February 22, 2014 7:59 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Policy blocker? Hi folks: I think this issue is resolved in the 4.3 branch. The default build system no longer seems to grab the mysql jar, and I've adjusted tomcat to load the mysql jar from the system library. Commit 0c2ad0338e34f6117cecc24ec00c7746dd481465 should have the necessary changes. I did some quick testing, and this seems to work, but obviously it needs more eyes and testing. --David On Thu, Feb 20, 2014 at 8:37 AM, David Nalley da...@gnsa.us wrote: Hi folks, I cringe to raise this issue. After 6 RCs I am sure we are all feeling a little bit of release vote fatigue. Especially Animesh. I apologize in advance; in all other respects I am ready to give a +1 to RC6. I've been playing with 4.3.0-rc6 for a couple of days now. I attempted to build some RPMs and had problems with dependency resolution in maven. This led me to looking at a number of different poms, and I noticed mysql-connector-java is listed as a runtime dependency. For our end users, this really isn't necessary - the debs and rpms specify a requirement (effectively a system requirement in the terms of policy) for mysql-connector-java. We don't need it to build the software (at least not in any location I've seen) - just when running. (And thus its a system dependency, much like MySQL is.) mysql-connector-java is GPLv2; which is Cat X. By including it as a dependency in the pom it automatically gets downloaded. The 3rd Party software policy has this line in it: YOU MUST NOT distribute build scripts or documentation within an Apache product with the purpose of causing the default/standard build of an Apache product to include any part of aprohibited work. We've released software with this dependency previously. Is this a blocker for 4.3 or do we fix going forward? (If we hadn't already shipped releases with this problem I'd lean a bit more towards it being a blocker - but its more murky now.) Thoughts, comments, flames? --David [1] https://www.apache.org/legal/3party.html
