[Updated with additional information.] Hello,
I'm pleased to announce the development of a new project called Mercador (Portuguese for “merchant”). Mercador will provide a mechanism for integrating OpenStack cloud services from one cloud service provider (CSP) into the set of services published by a second CSP. The mechanism is intended to be completely transparent to cloud service users, and to require minimal changes for participating CSPs. It is based on the concept of a virtual region, and builds on the hierarchical multitenant and Keystone-to-Keystone identity federation work in Kilo. This project is hosted on StackForge, initialized as a set of empty cookiecutter[1] repos: https://github.com/stackforge/mercador-pub https://github.com/stackforge/mercador-sub https://github.com/stackforge/python-mercadorclient Planning information for the project will be captured on Trello: https://trello.com/b/6tlmk3z4/mercador-stackforge-project Please join us via iRC on #openstack-mercador on freenode. I am holding a Doodle poll to select times for our first meeting. (I’ve reformatted the poll since the original announcement.) This Doodle poll will close June 8th and meeting times will be announced on the mailing list at that time. At our first IRC meeting, we will be selecting the core team members, so if you’re interested in participating in this project, please try to attend. http://doodle.com/fsdm6ry6aytqf7w8 The initial core team includes: Geoff Arnold David Cheperdak Orran Krieger Raildo Mascena For more details, check out our Wiki: https://wiki.openstack.org/wiki/Mercador In anticipation of a lively debate, I’m appending an FAQ [2] Regards, Geoff Arnold -- [1] https://github.com/openstack-dev/cookiecutter [2] FAQ Q. What exactly is this project going to build? A. The first deliverable is a system which will allow resources from CSP A to be made available to users of an OpenStack cloud operated by CSP B. We plan to demonstrate this in Tokyo. Q. Can’t we do that today? CERN already does this, and it was the theme of the Identity Federation demonstration at the Vancouver summit. A. Those examples all require administrators to collaborate on the static configuration of the various clouds. This system will support automated dynamic configuration. Q. How? A. The administrator of CSP A defines a set of “Virtual Regions”, each mapped into a Keystone Domain within one of her Regions. Then the admin of CSP B can select an available Virtual Region and make it available to his users just as though it was a regular Region of cloud B. (It shows up in Keystone and Horizon like other regions.) Q. How do the users of CSP B experience this? A. Users shouldn’t be able to tell the difference between one of CSP B’s own regions and a virtual region sourced from CSP A. (It should pass RefStack.) Q. How is this implemented? A. CSP A deploys a “publisher” service to define and publish Virtual Regions. CSP B deploys a “subscriber” service which talks to “publishers” to bind virtual regions. And there’s a CLI tool. Q. Is that all? A. The “publisher” is straightforward. The “subscriber” needs to be able to dynamically reconfigure Keystone and Horizon. This may require some minor changes. Q. How is resource allocation policy managed? How does CSP A control what’s available in a Virtual Region? A. In Kilo, the Keystone team implemented Hierarchical Multitenancy (HMT), but the rest of OpenStack isn’t HMT-aware. We need quotas in Nova, Cinder, etc. to be extended to support HMT. Q. This doesn’t meet my expectations for Service Federation. To me, Federation implies [insert list of cool intercloud functionality]. A. We’re concentrating on this one mechanism, which we think will be a foundation for a lot of interesting innovations. We’re collaborating with some of those, like the team from the Massachusetts Open Cloud. Q. There’s more to federation than simply wiring up the OpenStack services. What about operations and business integration – logging, metrics, billing, service assurance? A. You’re right. However right now most of those things are out of scope for OpenStack. We expect that the functionality we’re going to build will wind up being embedded in various OSS and BSS workflows. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
