Open Stack

> Core reviewers: 
> Please vote +1 if you ARE satisfied with integration with third party unusable without a license software, specifically Cinder volume drivers, Neutron network drivers, and various for-pay distributions of OpenStack and container runtimes. 
> Please vote –1 if you ARE NOT satisfied with integration with third party unusable without a license software, specifically Cinder volume drivers, Neutron network drivers, and various for pay distributions of OpenStack and container runtimes. 

> A bit of explanation on your vote might be helpful. 

> My vote is +1. I have already provided my rationale. 

> Regards, 
> -steve 

Sorry I'm a little late with my response.

I think it's good for us to allow outside parties in.  Our community is growing, but in order to get to the next level, we need to be welcoming of more outside parties.
Furthermore, I think having a defined structure on how outside parties will fit in is important so we maintain project organization.
The ideas that have been listed below I agree with. +1 for integration given our set of rules.

-Ryan

> __________________________________________________________________________ 
> OpenStack Development Mailing List (not for usage questions) 
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> Both arguments sound valid to me, both have pros and cons. 
> 
> I think it's valuable to look to the experiences of Cinder and Neutron in this area, both of which seem to have the same scenario and have existed much longer than Kolla. From what I know of how these operate, proprietary code is allowed to exist in the mainline so long as certain set of criteria is met. I'd have to look it up but I think it mostly comprises of the relevant parties must "play by the rules", e.g. provide a working CI, help with reviews, attend weekly meetings, etc. If Kolla can look to craft a similar set of criteria for proprietary code down the line, I think it should work well for us. 
> 
> Steve has a good point in that it may be too much overhead to implement a plugin system or similar up front. Instead, we should actively monitor the overhead in terms of reviews and code size that these extra implementations add. Perhaps agree to review it at the end of Mitaka? 
> 
> Given the project is young, I think it can also benefit from the increased usage and exposure from allowing these parties in. I would hope independent contributors would not feel rejected from not being able to use/test with the pieces that need a license. The libre distros will remain #1 for us. 
> 
> So based on the above explanation, I'm +1. 
> 
> -Paul 
> 
> __________________________________________________________________________ 
> OpenStack Development Mailing List (not for usage questions) 
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> Given Paul's comments I would agree here as well. I would like to get that 'criteria' required for Kolla to allow this proprietary code into the main repo down as soon as possible though and suggest that we have a bare minimum of being able to gate against it as one of the criteria. 
> 
> As for a plugin system, I also agree with Paul that we should check the overhead of including these other distros and any types needed after we have had time to see if they do introduce any additional overhead. 
> 
> So for the question 'Do we allow code that relies on proprietary packages?' I would vote +1, with the condition that we define the requirements of allowing that code as soon as possible. 
> 
> __________________________________________________________________________ 
> OpenStack Development Mailing List (not for usage questions) 
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> I am +1 on the system with following criteria we already discussed above 
> 
> - Set of defined requirements to adhere to for contributing and maintaining 
> - Set of contributors contributing to and reviewing the changes in Kolla. 
> - Set of maintainers available to connect with if we require any urgent attention to any failures in Kolla due to the code. 
> - CI if possible, we can evaluate the options as we finalize. 
> 
> Since we are on the subject of " OpenStack as a whole", I think OpenStack has evolved better with more operators contributing to the code base, since we need to let the code break to make it robust. This can be very easily observed with Cinder and Neutron specially, the different nature of implementations has always helped the base source improvements which were never thought of. 
> 
> I agree with Paul that Kolla benefit more with increased participation from Operators who are willing to update and use it. 
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev