Re: [openstack-dev] Separating our Murano PL core in own package

2014-03-25 Thread Serg Melikyan
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 
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




-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com

+7 (495) 640-4904, 0261
+7 (903) 156-0836
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Separating our Murano PL core in own package

2014-03-25 Thread Dmitry Teselkin
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


Re: [openstack-dev] Separating our Murano PL core in own package

2014-03-25 Thread Alexander Tivelkov
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.comwrote:

 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
 

Re: [openstack-dev] Separating our Murano PL core in own package

2014-03-24 Thread Serg Melikyan
Timur, I don't know about plans to support different languages for Murano
Engine. I think Murano PL may be valuable as standalone library, so I think
we should extract Murano PL code to separate package, and if we will need
it as a library it will be easy to extract to.


On Mon, Mar 24, 2014 at 12:48 AM, Timur Nurlygayanov 
tnurlygaya...@mirantis.com wrote:

 Hi Serg,

 This idea sounds good, I suggest to use name 'murano.engine.murano_pl'
 (not just common name like 'language' or 'dsl', but name, which will be
 based on 'MuranoPL')

 Do we plan to support the ability to define different languages for Murano
 Engine?


 Thank you!


 On Sun, Mar 23, 2014 at 1:05 PM, Serg Melikyan smelik...@mirantis.comwrote:

 There is a idea to separate core of Murano PL implementation from engine
 specific code, like it was done in PoC. When this two things are separated
 in different packages, we will be able to track and maintain our language
 core as clean as possible from engine specific code. This will give to us
 an ability to easily separate our language implementation to a library.

 Questions is under what name we should place core of Murano PL?

 1) muranoapi.engine.language;
 2) muranoapi.engine.dsl;
 3) suggestions?

 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com

 +7 (495) 640-4904, 0261
 +7 (903) 156-0836

 ___
 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




-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com

+7 (495) 640-4904, 0261
+7 (903) 156-0836
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Separating our Murano PL core in own package

2014-03-24 Thread Timur Sufiev
+1 for muranoapi.engine.murano_pl, because 'dsl'/'language' terms are too broad.

On Mon, Mar 24, 2014 at 12:48 AM, Timur Nurlygayanov
tnurlygaya...@mirantis.com wrote:
 Hi Serg,

 This idea sounds good, I suggest to use name 'murano.engine.murano_pl' (not
 just common name like 'language' or 'dsl', but name, which will be based on
 'MuranoPL')

 Do we plan to support the ability to define different languages for Murano
 Engine?


 Thank you!


 On Sun, Mar 23, 2014 at 1:05 PM, Serg Melikyan smelik...@mirantis.com
 wrote:

 There is a idea to separate core of Murano PL implementation from engine
 specific code, like it was done in PoC. When this two things are separated
 in different packages, we will be able to track and maintain our language
 core as clean as possible from engine specific code. This will give to us an
 ability to easily separate our language implementation to a library.

 Questions is under what name we should place core of Murano PL?

 1) muranoapi.engine.language;
 2) muranoapi.engine.dsl;
 3) suggestions?

 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com

 +7 (495) 640-4904, 0261
 +7 (903) 156-0836

 ___
 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




-- 
Timur Sufiev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Separating our Murano PL core in own package

2014-03-24 Thread Serg Melikyan
because 'dsl'/'language' terms are too broad.
Too broad in general, but we choose name for sub-package, and in murano
term 'language' mean Murano PL.

+1 for language


On Mon, Mar 24, 2014 at 11:26 AM, Timur Sufiev tsuf...@mirantis.com wrote:

 +1 for muranoapi.engine.murano_pl, because 'dsl'/'language' terms are too
 broad.

 On Mon, Mar 24, 2014 at 12:48 AM, Timur Nurlygayanov
 tnurlygaya...@mirantis.com wrote:
  Hi Serg,
 
  This idea sounds good, I suggest to use name 'murano.engine.murano_pl'
 (not
  just common name like 'language' or 'dsl', but name, which will be based
 on
  'MuranoPL')
 
  Do we plan to support the ability to define different languages for
 Murano
  Engine?
 
 
  Thank you!
 
 
  On Sun, Mar 23, 2014 at 1:05 PM, Serg Melikyan smelik...@mirantis.com
  wrote:
 
  There is a idea to separate core of Murano PL implementation from engine
  specific code, like it was done in PoC. When this two things are
 separated
  in different packages, we will be able to track and maintain our
 language
  core as clean as possible from engine specific code. This will give to
 us an
  ability to easily separate our language implementation to a library.
 
  Questions is under what name we should place core of Murano PL?
 
  1) muranoapi.engine.language;
  2) muranoapi.engine.dsl;
  3) suggestions?
 
  --
  Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
  http://mirantis.com | smelik...@mirantis.com
 
  +7 (495) 640-4904, 0261
  +7 (903) 156-0836
 
  ___
  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
 



 --
 Timur Sufiev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com

+7 (495) 640-4904, 0261
+7 (903) 156-0836
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Separating our Murano PL core in own package

2014-03-24 Thread Oleg Gelbukh
What does PL stand for, anyway?

--
Best regards,
Oleg Gelbukh


On Mon, Mar 24, 2014 at 11:39 AM, Serg Melikyan smelik...@mirantis.comwrote:

 because 'dsl'/'language' terms are too broad.
 Too broad in general, but we choose name for sub-package, and in murano
 term 'language' mean Murano PL.

 +1 for language


 On Mon, Mar 24, 2014 at 11:26 AM, Timur Sufiev tsuf...@mirantis.comwrote:

 +1 for muranoapi.engine.murano_pl, because 'dsl'/'language' terms are too
 broad.

 On Mon, Mar 24, 2014 at 12:48 AM, Timur Nurlygayanov
 tnurlygaya...@mirantis.com wrote:
  Hi Serg,
 
  This idea sounds good, I suggest to use name 'murano.engine.murano_pl'
 (not
  just common name like 'language' or 'dsl', but name, which will be
 based on
  'MuranoPL')
 
  Do we plan to support the ability to define different languages for
 Murano
  Engine?
 
 
  Thank you!
 
 
  On Sun, Mar 23, 2014 at 1:05 PM, Serg Melikyan smelik...@mirantis.com
  wrote:
 
  There is a idea to separate core of Murano PL implementation from
 engine
  specific code, like it was done in PoC. When this two things are
 separated
  in different packages, we will be able to track and maintain our
 language
  core as clean as possible from engine specific code. This will give to
 us an
  ability to easily separate our language implementation to a library.
 
  Questions is under what name we should place core of Murano PL?
 
  1) muranoapi.engine.language;
  2) muranoapi.engine.dsl;
  3) suggestions?
 
  --
  Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
  http://mirantis.com | smelik...@mirantis.com
 
  +7 (495) 640-4904, 0261
  +7 (903) 156-0836
 
  ___
  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
 



 --
 Timur Sufiev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com

 +7 (495) 640-4904, 0261
 +7 (903) 156-0836

 ___
 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


Re: [openstack-dev] Separating our Murano PL core in own package

2014-03-24 Thread Serg Melikyan
Programming Language, AFAIK


On Mon, Mar 24, 2014 at 11:46 AM, Oleg Gelbukh ogelb...@mirantis.comwrote:

 What does PL stand for, anyway?

 --
 Best regards,
 Oleg Gelbukh


 On Mon, Mar 24, 2014 at 11:39 AM, Serg Melikyan smelik...@mirantis.comwrote:

 because 'dsl'/'language' terms are too broad.
 Too broad in general, but we choose name for sub-package, and in murano
 term 'language' mean Murano PL.

 +1 for language


 On Mon, Mar 24, 2014 at 11:26 AM, Timur Sufiev tsuf...@mirantis.comwrote:

 +1 for muranoapi.engine.murano_pl, because 'dsl'/'language' terms are
 too broad.

 On Mon, Mar 24, 2014 at 12:48 AM, Timur Nurlygayanov
 tnurlygaya...@mirantis.com wrote:
  Hi Serg,
 
  This idea sounds good, I suggest to use name 'murano.engine.murano_pl'
 (not
  just common name like 'language' or 'dsl', but name, which will be
 based on
  'MuranoPL')
 
  Do we plan to support the ability to define different languages for
 Murano
  Engine?
 
 
  Thank you!
 
 
  On Sun, Mar 23, 2014 at 1:05 PM, Serg Melikyan smelik...@mirantis.com
 
  wrote:
 
  There is a idea to separate core of Murano PL implementation from
 engine
  specific code, like it was done in PoC. When this two things are
 separated
  in different packages, we will be able to track and maintain our
 language
  core as clean as possible from engine specific code. This will give
 to us an
  ability to easily separate our language implementation to a library.
 
  Questions is under what name we should place core of Murano PL?
 
  1) muranoapi.engine.language;
  2) muranoapi.engine.dsl;
  3) suggestions?
 
  --
  Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
  http://mirantis.com | smelik...@mirantis.com
 
  +7 (495) 640-4904, 0261
  +7 (903) 156-0836
 
  ___
  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
 



 --
 Timur Sufiev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com

 +7 (495) 640-4904, 0261
 +7 (903) 156-0836

 ___
 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




-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com

+7 (495) 640-4904, 0261
+7 (903) 156-0836
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Separating our Murano PL core in own package

2014-03-24 Thread Alexander Tivelkov
Hi Serg,

Are you proposing to have a standalone git repository / stack forge project
for that? Or just a separate package inside our primary murano repo?

--
Regards,
Alexander Tivelkov


On Mon, Mar 24, 2014 at 12:00 PM, Serg Melikyan smelik...@mirantis.comwrote:

 Programming Language, AFAIK


 On Mon, Mar 24, 2014 at 11:46 AM, Oleg Gelbukh ogelb...@mirantis.comwrote:

 What does PL stand for, anyway?

 --
 Best regards,
 Oleg Gelbukh


 On Mon, Mar 24, 2014 at 11:39 AM, Serg Melikyan 
 smelik...@mirantis.comwrote:

 because 'dsl'/'language' terms are too broad.
 Too broad in general, but we choose name for sub-package, and in murano
 term 'language' mean Murano PL.

 +1 for language


 On Mon, Mar 24, 2014 at 11:26 AM, Timur Sufiev tsuf...@mirantis.comwrote:

 +1 for muranoapi.engine.murano_pl, because 'dsl'/'language' terms are
 too broad.

 On Mon, Mar 24, 2014 at 12:48 AM, Timur Nurlygayanov
 tnurlygaya...@mirantis.com wrote:
  Hi Serg,
 
  This idea sounds good, I suggest to use name
 'murano.engine.murano_pl' (not
  just common name like 'language' or 'dsl', but name, which will be
 based on
  'MuranoPL')
 
  Do we plan to support the ability to define different languages for
 Murano
  Engine?
 
 
  Thank you!
 
 
  On Sun, Mar 23, 2014 at 1:05 PM, Serg Melikyan 
 smelik...@mirantis.com
  wrote:
 
  There is a idea to separate core of Murano PL implementation from
 engine
  specific code, like it was done in PoC. When this two things are
 separated
  in different packages, we will be able to track and maintain our
 language
  core as clean as possible from engine specific code. This will give
 to us an
  ability to easily separate our language implementation to a library.
 
  Questions is under what name we should place core of Murano PL?
 
  1) muranoapi.engine.language;
  2) muranoapi.engine.dsl;
  3) suggestions?
 
  --
  Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
  http://mirantis.com | smelik...@mirantis.com
 
  +7 (495) 640-4904, 0261
  +7 (903) 156-0836
 
  ___
  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
 



 --
 Timur Sufiev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com

 +7 (495) 640-4904, 0261
 +7 (903) 156-0836

 ___
 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




 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com

 +7 (495) 640-4904, 0261
 +7 (903) 156-0836

 ___
 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


Re: [openstack-dev] Separating our Murano PL core in own package

2014-03-24 Thread Serg Melikyan
Alexander, to have simple sub-package in muranoapi.engine/muranoapi


On Mon, Mar 24, 2014 at 1:43 PM, Alexander Tivelkov
ativel...@mirantis.comwrote:

 Hi Serg,

 Are you proposing to have a standalone git repository / stack forge
 project for that? Or just a separate package inside our primary murano repo?

 --
 Regards,
 Alexander Tivelkov


 On Mon, Mar 24, 2014 at 12:00 PM, Serg Melikyan smelik...@mirantis.comwrote:

 Programming Language, AFAIK


 On Mon, Mar 24, 2014 at 11:46 AM, Oleg Gelbukh ogelb...@mirantis.comwrote:

 What does PL stand for, anyway?

 --
 Best regards,
 Oleg Gelbukh


 On Mon, Mar 24, 2014 at 11:39 AM, Serg Melikyan 
 smelik...@mirantis.comwrote:

 because 'dsl'/'language' terms are too broad.
 Too broad in general, but we choose name for sub-package, and in murano
 term 'language' mean Murano PL.

 +1 for language


 On Mon, Mar 24, 2014 at 11:26 AM, Timur Sufiev tsuf...@mirantis.comwrote:

 +1 for muranoapi.engine.murano_pl, because 'dsl'/'language' terms are
 too broad.

 On Mon, Mar 24, 2014 at 12:48 AM, Timur Nurlygayanov
 tnurlygaya...@mirantis.com wrote:
  Hi Serg,
 
  This idea sounds good, I suggest to use name
 'murano.engine.murano_pl' (not
  just common name like 'language' or 'dsl', but name, which will be
 based on
  'MuranoPL')
 
  Do we plan to support the ability to define different languages for
 Murano
  Engine?
 
 
  Thank you!
 
 
  On Sun, Mar 23, 2014 at 1:05 PM, Serg Melikyan 
 smelik...@mirantis.com
  wrote:
 
  There is a idea to separate core of Murano PL implementation from
 engine
  specific code, like it was done in PoC. When this two things are
 separated
  in different packages, we will be able to track and maintain our
 language
  core as clean as possible from engine specific code. This will give
 to us an
  ability to easily separate our language implementation to a library.
 
  Questions is under what name we should place core of Murano PL?
 
  1) muranoapi.engine.language;
  2) muranoapi.engine.dsl;
  3) suggestions?
 
  --
  Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
  http://mirantis.com | smelik...@mirantis.com
 
  +7 (495) 640-4904, 0261
  +7 (903) 156-0836
 
  ___
  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
 



 --
 Timur Sufiev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com

 +7 (495) 640-4904, 0261
 +7 (903) 156-0836

 ___
 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




 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com

 +7 (495) 640-4904, 0261
 +7 (903) 156-0836

 ___
 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




-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com

+7 (495) 640-4904, 0261
+7 (903) 156-0836
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Separating our Murano PL core in own package

2014-03-24 Thread Stan Lagun
I like dsl most because it is
a. Short. This is especially good when you have that awesome 79-chars
limitation
b. It leaves a lot of room for changes. MuranoPL can change name. DSL - not
:)


On Mon, Mar 24, 2014 at 1:43 PM, Alexander Tivelkov
ativel...@mirantis.comwrote:

 Hi Serg,

 Are you proposing to have a standalone git repository / stack forge
 project for that? Or just a separate package inside our primary murano repo?

 --
 Regards,
 Alexander Tivelkov


 On Mon, Mar 24, 2014 at 12:00 PM, Serg Melikyan smelik...@mirantis.comwrote:

 Programming Language, AFAIK


 On Mon, Mar 24, 2014 at 11:46 AM, Oleg Gelbukh ogelb...@mirantis.comwrote:

 What does PL stand for, anyway?

 --
 Best regards,
 Oleg Gelbukh


 On Mon, Mar 24, 2014 at 11:39 AM, Serg Melikyan 
 smelik...@mirantis.comwrote:

 because 'dsl'/'language' terms are too broad.
 Too broad in general, but we choose name for sub-package, and in murano
 term 'language' mean Murano PL.

 +1 for language


 On Mon, Mar 24, 2014 at 11:26 AM, Timur Sufiev tsuf...@mirantis.comwrote:

 +1 for muranoapi.engine.murano_pl, because 'dsl'/'language' terms are
 too broad.

 On Mon, Mar 24, 2014 at 12:48 AM, Timur Nurlygayanov
 tnurlygaya...@mirantis.com wrote:
  Hi Serg,
 
  This idea sounds good, I suggest to use name
 'murano.engine.murano_pl' (not
  just common name like 'language' or 'dsl', but name, which will be
 based on
  'MuranoPL')
 
  Do we plan to support the ability to define different languages for
 Murano
  Engine?
 
 
  Thank you!
 
 
  On Sun, Mar 23, 2014 at 1:05 PM, Serg Melikyan 
 smelik...@mirantis.com
  wrote:
 
  There is a idea to separate core of Murano PL implementation from
 engine
  specific code, like it was done in PoC. When this two things are
 separated
  in different packages, we will be able to track and maintain our
 language
  core as clean as possible from engine specific code. This will give
 to us an
  ability to easily separate our language implementation to a library.
 
  Questions is under what name we should place core of Murano PL?
 
  1) muranoapi.engine.language;
  2) muranoapi.engine.dsl;
  3) suggestions?
 
  --
  Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
  http://mirantis.com | smelik...@mirantis.com
 
  +7 (495) 640-4904, 0261
  +7 (903) 156-0836
 
  ___
  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
 



 --
 Timur Sufiev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com

 +7 (495) 640-4904, 0261
 +7 (903) 156-0836

 ___
 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




 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com

 +7 (495) 640-4904, 0261
 +7 (903) 156-0836

 ___
 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




-- 
Sincerely yours
Stanislav (Stan) Lagun
Senior Developer
Mirantis
35b/3, Vorontsovskaya St.
Moscow, Russia
Skype: stanlagun
www.mirantis.com
sla...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Separating our Murano PL core in own package

2014-03-24 Thread Joshua Harlow
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

From: Stan Lagun sla...@mirantis.commailto:sla...@mirantis.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, March 24, 2014 at 3:27 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Separating our Murano PL core in own package

I like dsl most because it is
a. Short. This is especially good when you have that awesome 79-chars 
limitation
b. It leaves a lot of room for changes. MuranoPL can change name. DSL - not :)


On Mon, Mar 24, 2014 at 1:43 PM, Alexander Tivelkov 
ativel...@mirantis.commailto:ativel...@mirantis.com wrote:
Hi Serg,

Are you proposing to have a standalone git repository / stack forge project for 
that? Or just a separate package inside our primary murano repo?

--
Regards,
Alexander Tivelkov


On Mon, Mar 24, 2014 at 12:00 PM, Serg Melikyan 
smelik...@mirantis.commailto:smelik...@mirantis.com wrote:
Programming Language, AFAIK


On Mon, Mar 24, 2014 at 11:46 AM, Oleg Gelbukh 
ogelb...@mirantis.commailto:ogelb...@mirantis.com wrote:
What does PL stand for, anyway?

--
Best regards,
Oleg Gelbukh


On Mon, Mar 24, 2014 at 11:39 AM, Serg Melikyan 
smelik...@mirantis.commailto:smelik...@mirantis.com wrote:
because 'dsl'/'language' terms are too broad.
Too broad in general, but we choose name for sub-package, and in murano term 
'language' mean Murano PL.

+1 for language


On Mon, Mar 24, 2014 at 11:26 AM, Timur Sufiev 
tsuf...@mirantis.commailto:tsuf...@mirantis.com wrote:
+1 for muranoapi.engine.murano_pl, because 'dsl'/'language' terms are too broad.

On Mon, Mar 24, 2014 at 12:48 AM, Timur Nurlygayanov
tnurlygaya...@mirantis.commailto:tnurlygaya...@mirantis.com wrote:
 Hi Serg,

 This idea sounds good, I suggest to use name 'murano.engine.murano_pl' (not
 just common name like 'language' or 'dsl', but name, which will be based on
 'MuranoPL')

 Do we plan to support the ability to define different languages for Murano
 Engine?


 Thank you!


 On Sun, Mar 23, 2014 at 1:05 PM, Serg Melikyan 
 smelik...@mirantis.commailto:smelik...@mirantis.com
 wrote:

 There is a idea to separate core of Murano PL implementation from engine
 specific code, like it was done in PoC. When this two things are separated
 in different packages, we will be able to track and maintain our language
 core as clean as possible from engine specific code. This will give to us an
 ability to easily separate our language implementation to a library.

 Questions is under what name we should place core of Murano PL?

 1) muranoapi.engine.language;
 2) muranoapi.engine.dsl;
 3) suggestions?

 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.commailto:smelik...@mirantis.com

 +7 (495) 640-4904tel:%2B7%20%28495%29%20640-4904, 0261
 +7 (903) 156-0836tel:%2B7%20%28903%29%20156-0836

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.orgmailto: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.orgmailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Timur Sufiev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Serg Melikyan

Re: [openstack-dev] Separating our Murano PL core in own package

2014-03-24 Thread Ruslan Kamaldinov
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


[openstack-dev] Separating our Murano PL core in own package

2014-03-23 Thread Serg Melikyan
There is a idea to separate core of Murano PL implementation from engine
specific code, like it was done in PoC. When this two things are separated
in different packages, we will be able to track and maintain our language
core as clean as possible from engine specific code. This will give to us
an ability to easily separate our language implementation to a library.

Questions is under what name we should place core of Murano PL?

1) muranoapi.engine.language;
2) muranoapi.engine.dsl;
3) suggestions?

-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com

+7 (495) 640-4904, 0261
+7 (903) 156-0836
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] Separating our Murano PL core in own package

2014-03-23 Thread Timur Nurlygayanov
Hi Serg,

This idea sounds good, I suggest to use name 'murano.engine.murano_pl' (not
just common name like 'language' or 'dsl', but name, which will be based on
'MuranoPL')

Do we plan to support the ability to define different languages for Murano
Engine?


Thank you!


On Sun, Mar 23, 2014 at 1:05 PM, Serg Melikyan smelik...@mirantis.comwrote:

 There is a idea to separate core of Murano PL implementation from engine
 specific code, like it was done in PoC. When this two things are separated
 in different packages, we will be able to track and maintain our language
 core as clean as possible from engine specific code. This will give to us
 an ability to easily separate our language implementation to a library.

 Questions is under what name we should place core of Murano PL?

 1) muranoapi.engine.language;
 2) muranoapi.engine.dsl;
 3) suggestions?

 --
 Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
 http://mirantis.com | smelik...@mirantis.com

 +7 (495) 640-4904, 0261
 +7 (903) 156-0836

 ___
 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