Open Stack

Hi,

> I suggest to move all needed Powershell scripts and etc. to the main
repository 'murano' in the separate folder.

+1 on this. The scripts will not go inside the PyPi package, they will be
just grouped in a subfolder.

Completely agree on the repo-reorganization topic in general. However
> And I personally will do everything to prevent creation of new repo for
Murano.

Well, this may be unavoidable :)
We may face a need to create a "murano-contrib" repository where Murano
users will be able to contribute sources of their own murano packages,
improve the core library etc.
Given that we get rid of murano-conductor, murano-repository,
murano-metadataclient, murano-common, murano-tests and, probably,
murano-deployment, we are probably ok with having one more. Technically, we
may reuse murano-repository for this. But this can be discussed right
after there 0.5 release.


--
Regards,
Alexander Tivelkov


On Tue, Mar 25, 2014 at 12:09 PM, Timur Nurlygayanov <
tnurlygayanov at mirantis.com> wrote:

> Dmitry,
>
> I suggest to move all needed Powershell scripts and etc. to the main
> repository 'murano' in the separate folder.
>
>
> On Tue, Mar 25, 2014 at 11:38 AM, Dmitry Teselkin <dteselkin at mirantis.com>wrote:
>
>> Ruslan,
>>
>> What about murano-deployment repo? The most important part of it are
>> PowerSheel scripts, Windows Image Builder, package manifests, and some
>> other scripts that better to keep somewhere. Where do we plan to move them?
>>
>>
>> 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>
>>> wrote:
>>> > Seeing that the following repos already exist, maybe there is some
>>> need for
>>> > 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 to
>>> > have 1 repository (perhaps with submodules?) ;-)
>>> >
>>> > It appears like murano is already exploding all over stackforge which
>>> makes
>>> > it hard to understand why yet another repo is needed. I understand why
>>> from
>>> > 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
>>>
>>>
>>> Joshua,
>>>
>>> I agree that this huge number of repositories is confusing for
>>> newcomers. I've
>>> spent some time to understand mission of each of these repos. That's why
>>> we
>>> already did the cleanup :) [0]
>>>
>>> And I personally will do everything to prevent creation of new repo for
>>> Murano.
>>>
>>> Here is the list of repositories targeted for the next Murano release
>>> (Apr 17):
>>> * murano-api
>>> * murano-agent
>>> * python-muranoclient
>>> * murano-dashboard
>>> * murano-docs
>>>
>>> The rest of these repos will be deprecated right after the release.
>>>  Also we
>>> will rename murano-api to just "murano". murano-api will include all the
>>> Murano services, functionaltests for Tempest, Devstack scripts,
>>> developer docs.
>>> I guess we already can update README files in deprecated repos to avoid
>>> further
>>> confusion.
>>>
>>> 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 a
>>> 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 [1]. We shoul avoid referring to
>>> github
>>> since it's just a convinient mirror, while [1] is an official
>>> OpenStack repository.
>>>
>>> [0]
>>> https://blueprints.launchpad.net/murano/+spec/repository-reorganization
>>> [1] http://git.openstack.org/cgit/
>>>
>>>
>>>
>>> Thanks,
>>> Ruslan
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Thanks,
>> Dmitry Teselkin
>> Deployment Engineer
>> Mirantis
>> http://www.mirantis.com
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>
> Timur,
> QA Engineer
> OpenStack Projects
> Mirantis Inc
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140325/e64a4843/attachment.html>