Open Stack

On Mon, May 2, 2016 at 1:23 PM, Jeff Peeler <jpeeler at redhat.com> wrote:
> On Sun, May 1, 2016 at 5:03 PM, Steven Dake (stdake) <stdake at cisco.com> wrote:
>> I don't think a separate repository is the correct approach based upon one
>> off private conversations with folks at summit. Many people from that list
>> approached me and indicated they would like to see the work integrated in
>> one repository as outlined in my vote proposal email.  The reasons I heard
>> were:
>>
>> Better integration of the community
>> Better integration of the code base
>> Doesn't present an us vs them mentality that one could argue happened during
>> kolla-mesos
>> A second repository makes k8s a second class citizen deployment architecture
>> without a voice in the full deployment methodology
>> Two gating methods versus one
>> No going back to a unified repository while preserving git history
>>
>> I favor of the separate repositories I heard
>>
>> It presents a unified workspace for kubernetes alone
>> Packaging without ansible is simpler as the ansible directory need not be
>> deleted
>>
>> There were other complaints but not many pros.  Unfortunately I failed to
>> communicate these complaints to the core team prior to the vote, so now is
>> the time for fixing that.
>
> I favor the repository split, but the reason being is that I think
> Ansible along with Kubernetes should each be a separate repository.
> Keeping a monolithic repository is the opposite of the "Unix
> philosophy". It was even recommended at one point to split every
> single service into a separate repository [1].
>
> Repository management, backports, and additional gating are all things
> that I'll admit are more work with more than one single repository.
> However, the ease of ramping up where everything is separated out
> makes it worth it in my opinion. I believe the success of a given
> community is partially due to proper delineation of expertise
> (otherwise, why not put all OpenStack services in one gigantic repo?).
> I'm echoing this comment somebody said at the summit: stretching the
> core team across every orchestration tool is not scalable. I'm really
> hoping more projects will grow around the Kolla ecosystem and can do
> so without being required to become proficient with every other
> orchestration system.
>
> One argument for keeping a single repository is to compare to the
> mesos effort (that has stopped now) in a different repository. But as
> it has already been said, mesos should have been given fairness with
> ansible split out as well. If everything were in a single repository,
> it has been suggested that the community will review more. However, I
> don't personally believe that with gerrit in use that affects things
> at all. OpenStack even has a gerrit dashboard creator [2], but I think
> developers are capable enough at easily finding what they want to
> consistently review.
>
> As I said in a previous reply [3], I don't think git history should
> affect this decision as we can make it work in either scenario. ACL
> permissions seem overly complicated to be in the same repository, even
> if we can arrange for a feature branch to have different permissions
> from the main repo.
>
> My views here are definitely focused on the long term view. If any
> short term plans can be made to allow ourselves to eventually align
> with having separate repositories, I don't think I'd have a problem
> with that. However, I thought the Ansible code was supposed to have
> been separated out a long time ago. This is a natural inflection point
> to change policy and mode of operating, which is why I don't enjoy the
> idea of waiting any longer. Luckily, having Ansible in the same
> repository currently does not inhibit any momentum with Kubernetes in
> a separate repository.
>
> As far as starting the repositories split and then merging them in the
> future (assuming Ansible also stays in one repo), I don't know why we
> would want that. But perhaps after the Kubernetes effort has
> progressed we can better determine if that makes sense with a clear
> view of what the project files actually end up looking like. I don't
> think that any project that changes the containers' ABI is suitable to
> be labeled as "Kolla", so there wouldn't be any dockerfiles part of
> the repository.
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-April/093213.html
> [2] https://github.com/openstack/gerrit-dash-creator
> [3] http://lists.openstack.org/pipermail/openstack-dev/2016-May/093645.html

Jeff, I 100% agree here.

The strongest argument for single repo, IMO, is that it facilitates
code reviews for changes affecting both the container images and the
deployment tool, and makes it easier for backports.
On the other hand, having "better integration" as Steve put it, is not
always desirable: deployment tools each come with their specific
features and philosophy and I'd hate to see a patch receive negative
feedback because the developers can't agree on the "Kolla way" of
doing things. The quest for better integration and unified experience,
as noble as it can be, is also a slippery slope to delivering less
features. Requiring the kolla blessed deployment tools to support a
defined set of features is a good thing, limiting to these set of
features is not.

To a lesser extent, another thing I dislike about a single repository
is that it creates more noise for the kolla reviewers who only have
interest in one deployment tool.

I'm in favor of creating a separate repository for kolla-kubernetes
now and re-evaluate at the mid-cycle when the implementation has
maturated a bit and we have better feedback from the community.

Martin