Difference between revisions of "Mercador"
Geoff Arnold (talk | contribs) (Created page with "== What is Mercador? == Mercador is a system for federating independent OpenStack clouds. TK == Use cases == TK == Rationale == TK == Terminology == TK == Mercador archit...") |
Geoff Arnold (talk | contribs) |
||
| Line 2: | Line 2: | ||
Mercador is a system for federating independent OpenStack clouds. | Mercador is a system for federating independent OpenStack clouds. | ||
| − | + | ||
| + | As more organizations start to use OpenStack services from public cloud providers, OpenStack needs to support a variety of provider-consumer relationships. One natural pattern involved is a Service Aggregator: taking OpenStack services from two or more Cloud Service Providers (CSPs), and presenting them to a set of consumers through a single interface (provided by Horizon and Keystone). The natural unit of aggregation is the OpenStack region. However for various reasons discussed below, a CSP will generally not want to provide full access to a complete region. For this reason we introduce the concept of a Virtual Region, a construct whereby a CSP can construct a constrained view of a region, its resources, and the services available. | ||
| + | |||
| + | == Assumptions == | ||
| + | There are three important assumptions which affect the way in which Mercador has been designed. 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. Third, we assume that the life cycle of a provider-consumer binding is governed by business and operational interactions that are out of scope for OpenStack. | ||
| + | |||
| + | == 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 == | == Use cases == | ||
Revision as of 04:04, 28 May 2015
Contents
What is Mercador?
Mercador is a system for federating independent OpenStack clouds.
As more organizations start to use OpenStack services from public cloud providers, OpenStack needs to support a variety of provider-consumer relationships. One natural pattern involved is a Service Aggregator: taking OpenStack services from two or more Cloud Service Providers (CSPs), and presenting them to a set of consumers through a single interface (provided by Horizon and Keystone). The natural unit of aggregation is the OpenStack region. However for various reasons discussed below, a CSP will generally not want to provide full access to a complete region. For this reason we introduce the concept of a Virtual Region, a construct whereby a CSP can construct a constrained view of a region, its resources, and the services available.
Assumptions
There are three important assumptions which affect the way in which Mercador has been designed. 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. Third, we assume that the life cycle of a provider-consumer binding is governed by business and operational interactions that are out of scope for OpenStack.
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
