That’s the basic idea. Now, if you’re a reseller of cloud services, you deploy Horizon+Aggregator/Keystone behind your public endpoint, with your branding on Horizon. You then bind each of your Aggregator Regions to a Virtual Region from one of your providers. As a reseller, you don’t actually deploy the rest of OpenStack.
As for tokens, there are at least two variations, each with pros and cons: proxy and pass-through. Still working through implications of both. Geoff > On Apr 15, 2015, at 12:49 PM, Fox, Kevin M <kevin....@pnnl.gov> wrote: > > So, an Aggregator would basically be a stripped down keystone that basically > provided a dynamic service catalog that points to the registered other > regions? You could then point a horizon, cli, or rest api at the aggregator > service? > > I guess if it was an identity provider too, it can potentially talk to the > remote keystone and generate project scoped tokens, though you'd need > project+region scoped tokens, which I'm not sure exists today? > > Thanks, > Kevin > > ________________________________________ > From: Geoff Arnold [ge...@geoffarnold.com] > Sent: Wednesday, April 15, 2015 12:05 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [all] Introducing the Cloud Service Federation > project (cross-project design summit proposal) > > tl;dr We want to implement a new system which we’re calling an Aggregator > which is based on Horizon and Keystone, and that can provide access to > virtual Regions from multiple independent OpenStack providers. We plan on > developing this system as a project in Stackforge, but we need help right now > in identifying any unexpected dependencies. > > > > For the last 6-7 years, there has been great interest in the potential for > various business models involving multiple clouds and/or cloud providers. > These business models include but are not limited to, federation, reseller, > broker, cloud-bursting, hybrid and intercloud. The core concept of this > initiative is to go beyond the simple dyadic relationship between a cloud > service provider and a cloud service consumer to a more sophisticated “supply > chain” of cloud services, dynamically configured, and operated by different > business entities. This is an ambitious goal, but there is a general sense > that OpenStack is becoming stable and mature enough to support such an > undertaking. > > Until now, OpenStack has focused on the logical abstraction of a Region as > the basis for cloud service consumption. A user interacts with Horizon and > Keystone instances for a Region, and through them gains access to the > services and resources within the specified Region. A recent extension of > this model has been to share Horizon and Keystone instances between several > Regions. This simplifies the user experience and enables single sign on to a > “single pane of glass”. However, in this configuration all of the services, > shared or otherwise, are still administered by a single entity, and the > configuration of the whole system is essentially static and centralized. > > We’re proposing that the first step in realizing the Cloud Service Federation > use cases is to enable the administrative separation of interface and region: > to create a new system which provides the same user interface as today - > Horizon, Keystone - but which is administratively separate from the Region(s) > which provide the actual IaaS resources. We don’t yet have a good name for > this system; we’ve been referring to it as the “Aggregator”. It includes > slightly-modified Horizon and Keystone services, together with a subsystem > which configures these services to implement the mapping of “Aggregator > Regions” to multiple, administratively independent, “Provider Regions”. Just > as the User-Provider relationship in OpenStack is “on demand”, we want the > Aggregator-Provider mappings to be dynamic, established by APIs, rather than > statically configured. We want to achieve this without substantially changing > the user experience, and with no changes to applications or to core OpenStack > services. The Aggregator represents an additional way of accessing a cloud; > it does not replace the existing Horizon and Keystone. > > The functionality and workflow is as follows: A user, X, logs into the > Horizon interface provided by Aggregator A. The user sees two Regions, V1 and > V2, and selects V1. This Region is actually provided by OpenStack service > provider P; it’s the Region which P knows as R4. X now creates a new tenant > project, T. Leveraging the Hierarchical Multitenancy work in Kilo, T is > actually instantiated as a subproject of a Domain in R4, thus providing > namespace isolation and quota management. Now X can deploy and operate her > project T as she is used to, using Horizon, CLI, or other client-side tools. > UI and API requests are forwarded by the Aggregator to P’s Region R4. [I’ll > transfer this to the wiki and add diagrams.] > > As noted, the high-level workflow is relatively straightforward, but we need > to understand two important concepts. First, how does P make R4 available for > use by A? Are all of the services and resources in R4 available to A, or can > P restrict things in some way? What’s the lifecycle of the relationship? > Secondly, how do we handle identity? Can we arrange that same identity > provider is used in the Aggregator and in the relevant domain within R4? One > answer to these issues is to introduce what Mark Shuttleworth called “virtual > Regions” at his talk in Paris; add a layer which exposes a Domain within a > Region (with associated IDM, quotas, and other policies) as a browsable, > consumable resource aggregate. To implement this, P can add a new service to > R4, the Virtual Region Manager, with the twin roles of defining Virtual > Regions in terms of physical Region resources, and managing the service > provider side of the negotiation with the Aggregator when setting up > Aggregator-to-provider mappings. The intention is that the Virtual Region > Manager will be a non-disruptive add-on to an existing OpenStack deployment. > > Obviously there are many more issues to be solved, both within OpenStack and > outside (especially in the areas of OSS and BSS). However, we have the > beginnings of an architecture which seems to address many of the interesting > use cases. The immediate question is how to implement it within the OpenStack > process. It’s too complicated for any one of the existing OpenStack projects > to take it on; large-scale proposals rarely do well in this community. So we > intend to start this work as a new Stackforge project, with the objective of > completing a first version during the Liberty cycle. To meet this goal, we > must identify all of the features or fixes that we’ll need in other OpenStack > projects, and submit them for the Liberty cycle. (This is time critical!) > Hopefully each of these changes will be small enough that it can be accepted > without too much debate. The two projects most affected will be Keystone and > Horizon; in many cases, we will need to replace a static configuration with > something more dynamic. > > We think the time is right to begin this work. The Keystone team paved the > way during Kilo with their work on Hierarchical Multitenancy, and during the > Liberty cycle we expect to see work in other projects that will build on > this. (Hierarchical quotas, aggregated Ceilometer queries, that kind of > thing). By starting the Cloud Service Federation project within Stackforge, > we hope to avoid the “complexity antibodies”. However we really need to get > this proposal in front of OpenStack developers, because it’s critically > important to identify unexpected dependencies as soon as possible. For this > reason, we’d like to discuss it in Vancouver as part of the cross-project > track in the Design Summit. > > Geoff Arnold > Cisco Cloud Services > geoff(at)geoffarnold.com > geoarnol(at)cisco.com > @geoffarnold > > > > > > > > __________________________________________________________________________ > 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 __________________________________________________________________________ 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
