Open Stack

On Oct 11, 2013, at 18:02 , Russell Bryant <rbryant at redhat.com>
 wrote:

> On 10/11/2013 10:41 AM, Alessandro Pilotti wrote:
>> 
>> 
>> On Oct 11, 2013, at 17:17 , Russell Bryant <rbryant at redhat.com
>> <mailto:rbryant at redhat.com>>
>> wrote:
>> 
>>> On 10/11/2013 09:02 AM, Alessandro Pilotti wrote:
>>>> OpenStack is organized differently: there are lots of separate
>>>> projects (Nova, Neutrom, Glance, etc) instead of a single one (which
>>>> is a good thing), but I believe that a similar approach can be
>>>> applied. Specific contributors can be nominated "core rewievers" on
>>>> specific directories in the tree only and that would scale
>>>> immediately the core review bandwidth.
>>>> 
>>>> As a practical example for Nova: in our case that would simply
>>>> include the following subtrees: "nova/virt/hyperv" and
>>>> "nova/tests/virt/hyperv". Other projects didn't hit the review
>>>> bandwidth limits yet as heavily as Nova did, but the same concept
>>>> could be applied everywhere.
>>> 
>>> If maintainers of a particular driver would prefer this sort of
>>> autonomy, I'd rather look at creating new repositories.  I'm completely
>>> open to going that route on a per-driver basis.  Thoughts?
>> 
>> Well, as long as it is an official project this would make definitely
>> sense, at least for Hyper-V.
> 
> What I envision here would be another repository/project under the
> OpenStack Compute program.  You can sort of look at it as similar to
> python-novaclient, even though that project uses the same review team
> right now.
> 
> So, that means it would also be a separate release deliverable.  It
> wouldn't be integrated into the main nova release.  They could be
> released at the same time, though.
> 
> We could either have a single repo:
> 
>    openstack/nova-extra-drivers
> 
> or a repo per driver that wants to split:
> 
>    openstack/nova-driver-hyperv
> 

+1 for openstack/nova-driver-hyperv

That would be perfect. Fast bug fixes, independent reviewers and autonomous blueprints management.

Our users would cry of joy for such a solution. :-)


> The latter is a bit more to keep track of, but might make the most sense
> so that we can have a review team per driver.
> 
>> Stability of the driver's interface has never been a particular issue to
>> prevent this to happen IMO.
> 
> Note that I would actually *not* want to necessarily guarantee a stable
> API here for master.  We should be able to mitigate sync issues with CI.
> 
>> We should think about how to handle the testing, considering that we are
>> getting ready with the CI gate.
> 
> Hopefully the testing isn't too much different.  It's just grabbing the
> bits from another repo.
> 
> Also note that I have a session for the summit that is intended to talk
> about all of this, as well:
> 
>    http://summit.openstack.org/cfp/details/4

Sure, looking forward to meet you there!

> 
> -- 
> Russell Bryant
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev