Mercador
Contents
What is Mercador?
Mercador is a system for federating independent OpenStack clouds. The name comes from the Portuguese word for merchant.
The basic consumption model for cloud services is a simple two-party interaction between a Cloud Service User (CSU) and a Cloud Service Provider (CSP). The CSP deploys a set of services and publishes them though a standard interface supporting UI, CLI, and API. The CSU subscribes to this bundle of services (using a mechanism that is generally out of scope for OpenStack), and consumes the services via the published interfaces. No matter how complex or geographically distributed the services, they are all owned and operated by a single legal entity, which has complete control over how they are configured and managed.
A number of use cases are emerging which require us to extend this model. CSPs operating private clouds wish to provide uniform access for their users to both private and public cloud services. A CSP operating in one geography wants to offer services hosted in a different country (for data sovereignty reasons); rather than setting up an OpenStack cloud in that country, it elects to source those services from another CSP. A telco decides that it wants to offer cloud services to its customers, but doesn't have the expertise to do so; instead it prefers to resell services from one or more CSPs under its own brand. A research consortium wants to aggregate cloud services from several university CSPs and present the aggregated services to its users through a "single pane of glass".
The common pattern in all of these cases is that we need to be able to take a bundle of resources and services from one CSP and make them available to a second CSP in such a way that they can be treated as part of the second CSPs service offering. A CSU should be unaware whether the services being consumed are implemented by the CSP with which they have a contractual relationship or by a third party. In the extreme case of a CSP acting as a pure reseller, they may not operate any services for themselves.
Principles
There are four important principles which affect the way in which Mercador is being developed.
- First, we assume that the various actors - providers, consumers, resellers, brokers, etc. - are independent agents; there is no single authority that can impose and manage an overarching configuration.
- Second, we assume that the various relationships are dynamic, but not ephemeral. This means that the system must support both the construction of a publish-subscribe binding as well as the long-term management of the relationship.
- Third, we assume that the life cycle of a publish-subscribe binding is governed by business and operational interactions that are out of scope for OpenStack, and that the lifecycle of the binding can be integrated into workflows associated with these interactions.
- Fourth, we want Mercador to be minimally intrusive. Ideally, a CSP should be able to publish resources by deploying a single service - the Mercador publisher - which will add one service to the Service Catalog. A CSP should be able to discover and subscribe to services by deploying a Mercador subscriber. Both services are administered using a common CLI. The CSU should not see any changes.
User stories
Actors
- Cumulus, Cirrus and Nimbus are three OpenStack IaaS operators (Cloud Service Providers,or CSPs). Cumulus and Cirrus offer public cloud services. Nimbus is primarily in the business of supporting its SaaS activities.
- Chris and Pat are two developers working for Widget Corp.
- Acme Corp is a reseller of OpenStack cloud services.
User Story #1:
Widget wishes to provide OpenStack services to its developers to build in-house applications. For business reasons, it wants to use multiple cloud providers, but it wants to provide its developers with a single, consistent user experience. It contracts with Cumulus and Cirrus to provide OpenStack services. It deploys a Service Aggregator which allows Chris and Pat to use a single Horizon and Keystone to access the two clouds.
User Story #2:
Nimbus decides to raise revenue by reselling some of its IaaS capacity. However it does not want the complications of sales, support and billing to end users. Instead it contracts with Acme to resell its OpenStack services.
User Story #3:
Cirrus wishes to add a new OpenStack service, BDaaS (using Sahara). However it has no in-house expertise in supporting big data applications. Cirrus decides to subcontract the resale of OpenStack services with BDaaS to Acme, while preventing its existing customers like Widget from having access to BDaaS. It does this by creating two Virtual Regions. One Virtual Region includes BDaaS, and is made available to Acme; the other does not, and is provided to Widget.
User Story #4:
Cumulus suffers a major outage, and Widget decides that it needs to switch to another provider. It contracts with Acme to provide OpenStack services. Acme satisfies this contract using services from Nimbus (Story #2). Widget reconfigures its Service Aggregator, replacing the Cumulus configuration with one for Acme.
User Story #5:
The outage at Cumulus continues, and Cumulus decides that they need to add capacity from a third party so that they can continue to service their customers. Cumulus contracts with Cirrus to provide OpenStack services. Cirrus creates a Virtual Region, and makes it available to Cumulus. Cumulus configures this Virtual Region to use its existing IDM solution, so that its existing customers can log in using their regular credentials.
Use cases
TK
Rationale
TK
Terminology
TK
Mercador architecture
TK
Releases
TK
Development (Blueprints, Roadmap, Design...)
TK
Links & IRC
TK
Team
TK
FAQ
TK
