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 < tnurlygaya...@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 > <dtesel...@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 < >> rkamaldi...@mirantis.com> wrote: >> >>> On Mon, Mar 24, 2014 at 10:08 PM, Joshua Harlow <harlo...@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@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@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev