Open Stack

Excerpts from Alexander Tivelkov's message of 2014-01-21 11:55:34 -0800:
> Hi folks,
> 
> As we are moving towards incubation application, I took a closer look at
> what is going on with our repositories.
> An here is what I found. We currently have 11 repositories at stackforge:
> 
>    - murano-api
>    - murano-conductor
>    - murano-repository
>    - murano-dashboard
>    - murano-common
>    - python-muranoclient
>    - murano-metadataclient
>    - murano-agent
>    - murano-docs
>    - murano-tests
>    - murano-deployment
> 
> This enourmous amount of repositories adds too much infrustructural
> complexity, and maintaining the changes in in consistent and reliable
> manner becomes a really tricky tasks. We often have changes which require
> modifing two or more repositories - and thus we have to make several
> changesets in gerrit, targeting different repositories. Quite often the
> dependencies between these changesets are not obvious, the patches get
> reviewed and approved on wrong order (yes, this also questions the quality
> of the code review, but that is a different topic), which causes in
> inconsostent state of the repositories.
> 

So, as somebody who does not run Murano, but who does care a lot about
continuous delivery, I actually think keeping them separate is a great
way to make sure you have ongoing API stability.

Since all of those pieces can run on different machines, having the APIs
able to handle both "the old way" and "the new way" is quite helpful in
a large scale roll out where you want to keep things running while you
update.

Anyway, that may not matter much, but it is one way to think about it.