[openstack-dev] Separating our Murano PL core in own package
smelikyan at mirantis.com
Tue Mar 25 07:21:09 UTC 2014
Joshua, I was talking about simple python sub-package inside existing
repository, in existing package. I am suggesting to add
muranoapi.engine.<name> sub-package, and nothing more.
On Mon, Mar 24, 2014 at 10:29 PM, Ruslan Kamaldinov <
rkamaldinov at mirantis.com> wrote:
> On Mon, Mar 24, 2014 at 10:08 PM, Joshua Harlow <harlowja at yahoo-inc.com>
> > Seeing that the following repos already exist, maybe there is some need
> > cleanup?
> > - https://github.com/stackforge/murano-agent
> > - https://github.com/stackforge/murano-api
> > - https://github.com/stackforge/murano-common
> > - https://github.com/stackforge/murano-conductor
> > - https://github.com/stackforge/murano-dashboard
> > - https://github.com/stackforge/murano-deployment
> > - https://github.com/stackforge/murano-docs
> > - https://github.com/stackforge/murano-metadataclient
> > - https://github.com/stackforge/murano-repository
> > - https://github.com/stackforge/murano-tests
> > ...(did I miss others?)
> > Can we maybe not have more git repositories and instead figure out a way
> > have 1 repository (perhaps with submodules?) ;-)
> > It appears like murano is already exploding all over stackforge which
> > it hard to understand why yet another repo is needed. I understand why
> > a code point of view, but it doesn't seem right from a code organization
> > point of view to continue adding repos. It seems like murano
> > (https://github.com/stackforge/murano) should just have 1 repo, with
> > sub-repos (tests, docs, api, agent...) for its own organizational usage
> > instead of X repos that expose others to murano's internal organizational
> > details.
> > -Josh
> I agree that this huge number of repositories is confusing for newcomers.
> spent some time to understand mission of each of these repos. That's why we
> already did the cleanup :) 
> And I personally will do everything to prevent creation of new repo for
> Here is the list of repositories targeted for the next Murano release (Apr
> * murano-api
> * murano-agent
> * python-muranoclient
> * murano-dashboard
> * murano-docs
> The rest of these repos will be deprecated right after the release. Also
> will rename murano-api to just "murano". murano-api will include all the
> Murano services, functionaltests for Tempest, Devstack scripts, developer
> I guess we already can update README files in deprecated repos to avoid
> I wouldn't agree that there should be just one repo. Almost every OpenStack
> project has it's own repo for python client. All the user docs are kept in
> separate repo. Guest agent code should live in it's own repository to keep
> number of dependencies as low as possible. I'd say there should be
> required/comfortable minimum of repositories per project.
> And one more nit correction:
> OpenStack has it's own git repository . We shoul avoid referring to
> since it's just a convinient mirror, while  is an official
> OpenStack repository.
>  http://git.openstack.org/cgit/
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelikyan at mirantis.com
+7 (495) 640-4904, 0261
+7 (903) 156-0836
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev