On 04/15/2015 04:23 PM, Geoff Arnold wrote:
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


Read the Keysteon to Keystone (K2K) docs in the Keystone spec repo, as that addresses some of the issues here.


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



__________________________________________________________________________
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

Reply via email to