Re: [DISCUSS] Policy blocker?

[Sebastien Goasguen]

On Feb 21, 2014, at 7:37 PM, Animesh Chaturvedi  
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?

[David Nalley]

On Sat, Feb 22, 2014 at 3:07 AM, Sebastien Goasguen  wrote:
>
> On Feb 21, 2014, at 7:37 PM, Animesh Chaturvedi 
>  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

[Miguel Ferreira]

> 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

[Miguel Ferreira]

---
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

[Niels de Vos]

> 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  server.allow-insecure on
# gluster volume stop 
# gluster volume start 

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  storage.owner-uid 36
# gluster volume set  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

[Joris van Lieshout]

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" 
mailto: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 
mailto: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 Diff

Re: Review Request 18310: dnsmasq fix for bridged networks

[Joris van Lieshout]

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" 
mailto: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 
mailto: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 Diff

RE: [DOCS][DISCUSS] heads-up main docs repo refactor

[Radhika Puthiyetath]

Thanks Sebastien.

Let me cross-verify all my 4.3 feature docs are submitted. Once 4.3 is out, I 
can spend some time on learning RST.

-Radhika

-Original Message-
From: sebgoa [mailto:run...@gmail.com] 
Sent: Friday, February 21, 2014 8:48 PM
To: dev@cloudstack.apache.org
Cc: Animesh Chaturvedi; Hugo Trippaers; Dave Cahill; Yoshikazu Nojima
Subject: Re: [DOCS][DISCUSS] heads-up main docs repo refactor


On Feb 20, 2014, at 6:11 PM, Radhika Puthiyetath 
 wrote:

> Hi,
> 
> From Citrix-perspective, this is going to be effort intensive considering the 
> current head count for documentation. 
> 
> For 4.3, we would like to continue with DocBook, as per our earlier 
> consensus. 
> 
> I shall come back with a concrete plan soon after completing the 4.3 feature 
> documentation. 
> 
> Hope it works. Thanks for your patience.
> 
> -Radhika

Radhika, I went through all the commits on master and 4.3 branch and made sure 
I ported everything to RTD.
We are good to go up to your latest commit on Feb 6th: 
58ec1d0091f80845412b42543191acc1e976383b

There are some issues with the content, I see a missing file. So I ported what 
I could and left some.

So from my standpoint we can switch to RTD now for all docs (master and 4.3 
content is all in).
The RN are ready, the install guide is ready, most of the dev guide is ready 
and I should be done today.
That leaves the admin guide to format but I will start today and should be done 
before 4.3 is voted.

Bottom line all commits have been migrated to RTD and .rst format.

-Sebastien

> 
> -Original Message-
> From: sebgoa [mailto:run...@gmail.com] 
> Sent: Thursday, February 20, 2014 8:50 PM
> To: dev@cloudstack.apache.org; Radhika Puthiyetath
> Cc: Animesh Chaturvedi; Hugo Trippaers; Dave Cahill; Yoshikazu Nojima
> Subject: [DOCS][DISCUSS] heads-up main docs repo refactor
> 
> Hi,
> 
> With the change of format for docs, I have started to refactor the main docs 
> repo "cloudstack-docs.git"
> 
> The allocator,midonet,nicira,qig,vxlan and release notes guides have been 
> converted to .rst format.
> 
> I am moving the docbook version of these guides into an /archive directory 
> for the time being.
> 
> I will move my github repo that is used to build 
> http://cloudstack.readthedocs.org/en/latest/ to the main docs repo.
> 
> The release notes now have their main repo and are up to date for 4.3 release.
> 
> Now for the [DISCUSS] part:
> 
> * The install and admin guides also have their own repo so we could remove 
> them from cloudstack-docs with a temporary move to the /archive dir .
> 
> *My thought is to keep the cloudstack-docs repo for a "catch all" docs where 
> people can contribute "guides" that stand on their own, while the admin and 
> install repos are for the complete guides that we need to improve as complete 
> end-to-end docs.
> 
> * @Radhika you are mostly the only one writing in docbook, when do you feel 
> comfortable switching to .rst ? I am willing to help clean up the period when 
> we have a few left over docbook commits that need to be merged in .rst. But 
> we do need to have date at which point we make docbook "obsolete". I have 
> already started going through your last 10 commits to make sure the content 
> is in the new format.
> 
> thoughts,
> 
> -Sebastien

Re: [DISCUSS] Policy blocker?

[David Nalley]

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  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?

[Rayees Namathponnan]

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  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