<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:宋体;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@宋体";
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:宋体;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:宋体;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"批注框文本 Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:9.0pt;
font-family:宋体;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.Char
{mso-style-name:"批注框文本 Char";
mso-style-priority:99;
mso-style-link:批注框文本;
font-family:宋体;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="2050" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="ZH-CN" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Hello, Geoff,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Interesting idea to build a virtual region.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">We are also using “OpenStack cascading solution”(<a href="https://wiki.openstack.org/wiki/OpenStack_cascading_solution">https://wiki.openstack.org/wiki/OpenStack_cascading_solution</a>)
to build the virtual region for tenant:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">The idea is to build tenant level virtual OpenStack ( mainly Nova,Cinder,Neutron, Ceilometer, Glance ) service over hybrid or federated or multiple
OpenStack based clouds based on OpenStack cascading solution. The cascading OpenStack is to function as virtual resources ( VM, Volume, Network.. ) addressing and routing to corresponding cascaded OpenStack where the virtual resources of this tenant are allocated
and interconnected. The cascading OpenStack becomes only one control layer, no data plane involved.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:18.0pt;margin-left:0cm;line-height:14.4pt;background:white;vertical-align:baseline">
<span lang="EN-US" style="font-size:9.5pt;font-family:"Helvetica","sans-serif";color:#4D4F51">For the large scale or hybrid cloud provider, when the tenant access his/her cloud resources, will be redirected to the portal/API endpoint of the cascading OpenStack
allocated for him/her, no matter how large scale the cloud is, how many OpenStack resources pool (or even hybrid resources) behind the cloud.
<o:p></o:p></span></p>
<p style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:18.0pt;margin-left:0cm;line-height:14.4pt;background:white;vertical-align:baseline">
<span lang="EN-US" style="font-size:9.5pt;font-family:"Helvetica","sans-serif";color:#4D4F51">These clouds behind the cascading OpenStack may be federated with KeyStone, or using shared KeyStone, or even some OpenStack clouds built in AWS or Azure, or VMWare
vSphere. As the driver for AWS/Azure developed for cascading, even hybrid-cloud can be integrated behind the cascading OpenStack.<o:p></o:p></span></p>
<p style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:18.0pt;margin-left:0cm;line-height:14.4pt;background:white;vertical-align:baseline;font-stretch: inherit;box-sizing: border-box;orphans: auto;text-align:start;widows: 1;-webkit-text-stroke-width: 0px;word-spacing:0px">
<span lang="EN-US" style="font-size:9.5pt;font-family:"Helvetica","sans-serif";color:#4D4F51">Under this deployment scenario, unlimited scalability in a cloud can be achieved, no unified cascading layer, tenant level resources orchestration among multi-OpenStack
clouds fully distributed(even geographically), no central point at all. The database and load for one casacding OpenStack is very very small, easy for disaster recovery or backup.<o:p></o:p></span></p>
<p style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:18.0pt;margin-left:0cm;line-height:14.4pt;background:white;vertical-align:baseline;font-stretch: inherit;box-sizing: border-box;orphans: auto;text-align:start;widows: 1;-webkit-text-stroke-width: 0px;word-spacing:0px">
<span lang="EN-US" style="font-size:9.5pt;font-family:"Helvetica","sans-serif";color:#4D4F51">Multiple tenant may share one cascading OpenStack to reduce resource waste, but the principle is to keep the cascading OpenStack as thin as possible.<o:p></o:p></span></p>
<p style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:18.0pt;margin-left:0cm;line-height:14.4pt;background:white;vertical-align:baseline">
<span lang="EN-US" style="font-size:9.5pt;font-family:"Helvetica","sans-serif";color:#4D4F51">it's easier to understand the idea from the following picture. (if you cannot see the picture in the mail, please jump to the link
<a href="http://www.linkedin.com/pulse/world-without-openstack-scalability-issue-joe-huang">
http://www.linkedin.com/pulse/world-without-openstack-scalability-issue-joe-huang</a>)<o:p></o:p></span></p>
<p style="mso-margin-top-alt:0cm;margin-right:0cm;margin-bottom:18.0pt;margin-left:0cm;line-height:14.4pt;background:white;vertical-align:baseline">
<span lang="EN-US" style="font-size:9.5pt;font-family:"Helvetica","sans-serif";color:#4D4F51"><img border="0" width="951" height="541" id="图片_x0020_6" src="cid:image001.png@01D07B61.79B2F5C0" alt="http://hi3ms-image.huawei.com/hi/showimage-1423659627-27165-714ba07856a90c3c437b87783c40fc5d.jpg"></span><span lang="EN-US" style="font-size:9.5pt;font-family:"Helvetica","sans-serif";color:#4D4F51"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-align:justify;text-justify:inter-ideograph"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Best Regards<o:p></o:p></span></p>
<p class="MsoNormal" style="text-align:justify;text-justify:inter-ideograph"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Chaoyi Huang ( Joe Huang )<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Geoff Arnold [mailto:geoff@geoffarnold.com]
<br>
<b>Sent:</b> Friday, April 17, 2015 6:58 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [all] Introducing the Cloud Service Federation project (cross-project design summit proposal)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Joe: you have identified many of the challenges of trying to work with multiple OpenStack clouds from different providers with different configurations, resources, etc. Nevertheless, people are doing it, and doing so
successfully. (I know several teams that are running across multiple public and private clouds.) Packaging solutions like Docker may help with some of the low-level compatibility issues.<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">This proposal is intended to remove one source of friction. There’s a lot more to be done. One interesting avenue for research is going to be the development of a "virtual region" metadata schema that will allow a tenant
(or a broker) to determine the characteristics of virtual regions. (Such a model might be a useful complement to the RefStack work.)<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Geoff<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"> <o:p></o:p></span></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span lang="EN-US">On Apr 16, 2015, at 3:00 PM, Joe Gordon <<a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a>> wrote:<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">On Thu, Apr 16, 2015 at 12:16 AM, Geoff Arnold <<a href="mailto:geoff@geoffarnold.com" target="_blank">geoff@geoffarnold.com</a>> wrote:<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">I’ve discussed this with the Keystone team, especially the Reseller folks, but not as deeply as we need to.<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">The biggest challenge that I see with doing this inside any existing project is the Aggregator system. It’s an independent deployment that doesn’t include any of the core OpenStack IaaS services - there’s no Nova, no
networking (Nova or Neutron), no Glance, no Cinder. It’s just Horizon, Keystone, and a bunch of orchestration logic to wire up the virtual regions. Just assembling the bits into a deployable and testable system is going to be significantly different from a
regular OpenStack cloud. Even though OpenStack is composed of relatively independent services, there’s an assumed context which affects just about everything. I really wouldn’t ask Keystone to take on the responsibility for such a thing. Better to build it
in Stackforge, get some experience with it, and figure out where it lives later on.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">In spite of all that, we believe that this belongs in the “big tent” OpenStack, because it builds on existing OpenStack component services, and it’s value depends on interoperability. If you deploy the Virtual Region
service as part of your OpenStack cloud, any Aggregator should be able to re-present your virtual regions to its users (subject to obvious security and operational policies). We’ve used the Reseller use case to describe the workflows, but there are a number
of equally important use cases for this architecture. <o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">'interoperability' is where I can see a lot of issues arising. If I am using a reseller with regions from two different providers that are configured even slightly differently, using the two regions interchangeably will
become exceedingly difficult quickly. There are many cases where the same API when powered by different drivers and slightly different configurations result in very different end user behavior. A few example issues:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">* Glance images maintained by the cloud provider would be different across providers.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">* Policy files dictating what API calls a given user can use can differ across providers.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">* Network models. There is no single network model for OpenStack.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">* CPU performance. OpenStack has no way of saying 1VCPU in provider X is equivalent to 1.5 VCPUs under provider Y.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">* Config driver vs. metadata service.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">* Those are just a few issues I can think of off the top of my head but there are many many more.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">I can see this model working for only the simplest of use cases. Maintaining a cohesive experience across multiple providers who may not be working together is very difficult. But perhaps I am missing something.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:#888888"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:#888888">Geoff<o:p></o:p></span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span lang="EN-US">On Apr 15, 2015, at 10:03 PM, Miguel Angel Ajo Pelayo <<a href="mailto:mangelajo@redhat.com" target="_blank">mangelajo@redhat.com</a>> wrote:<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">Sounds like a very interesting idea.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US">Have you talked to the keystone folks?,<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">I would do this work into the keystone project itself (just a separate daemon).<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">This still looks like identity management (federated, but identity)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">I know the burden of working with a mainstream project could be higher, but benefits<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">are also higher: it becomes more useful (it becomes automatically available for everyone)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">and also passes through the review process of the general keystone contributors, thus<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">getting a more robust code.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Best regards,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Miguel <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span lang="EN-US">On 16/4/2015, at 6:24, Geoff Arnold <<a href="mailto:geoff@geoffarnold.com" target="_blank">geoff@geoffarnold.com</a>> wrote:<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">Yeah, we’ve taken account of:<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US"><a href="https://github.com/openstack/keystone-specs/blob/master/specs/juno/keystone-to-keystone-federation.rst" target="_blank">https://github.com/openstack/keystone-specs/blob/master/specs/juno/keystone-to-keystone-federation.rst</a><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><a href="http://blog.rodrigods.com/playing-with-keystone-to-keystone-federation/" target="_blank">http://blog.rodrigods.com/playing-with-keystone-to-keystone-federation/</a><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><a href="http://docs.openstack.org/developer/keystone/configure_federation.html" target="_blank">http://docs.openstack.org/developer/keystone/configure_federation.html</a><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">One of the use cases we’re wrestling with requires fairly strong anonymization: if user A purchases IaaS services from reseller B, who sources those services from service provider C, nobody at C (OpenStack admin, root
on any box) should be able to identify that A is consuming resources; all that they can see is that the requests are coming from B. It’s unclear if we should defer this requirement to a future version, or whether there’s something we need to (or can) do now.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">The main focus of Cloud Service Federation is managing the life cycle of virtual regions and service chaining. It builds on the Keystone federated identity work over the last two cycles, but identity is only part of the
problem. However, I recognize that we do have an issue with terminology. For a lot of people, “federation” is simply interpreted as “identity federation”. If there’s a better term than “cloud service federation”, I’d love to hear it. (The Cisco term “Intercloud”
is accurate, but probably inappropriate!)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Geoff<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span lang="EN-US">On Apr 15, 2015, at 7:07 PM, Adam Young <<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>> wrote:<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">On 04/15/2015 04:23 PM, Geoff Arnold wrote:<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">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.<br>
<br>
As for tokens, there are at least two variations, each with pros and cons: proxy and pass-through. Still working through implications of both.<br>
<br>
Geoff<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><br>
<br>
Read the Keysteon to Keystone (K2K) docs in the Keystone spec repo, as that addresses some of the issues here.<br>
<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">On Apr 15, 2015, at 12:49 PM, Fox, Kevin M <<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>> wrote:<br>
<br>
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?<br>
<br>
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?<br>
<br>
Thanks,<br>
Kevin<br>
<br>
________________________________________<br>
From: Geoff Arnold [<a href="mailto:geoff@geoffarnold.com" target="_blank">geoff@geoffarnold.com</a>]<br>
Sent: Wednesday, April 15, 2015 12:05 PM<br>
To: OpenStack Development Mailing List (not for usage questions)<br>
Subject: [openstack-dev] [all] Introducing the Cloud Service Federation project (cross-project design summit proposal)<br>
<br>
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.<br>
<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.]<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Geoff Arnold<br>
Cisco Cloud Services<br>
geoff(at)<a href="http://geoffarnold.com/" target="_blank">geoffarnold.com</a><br>
geoarnol(at)<a href="http://cisco.com/" target="_blank">cisco.com</a><br>
@geoffarnold<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">
OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">
OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">
OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">
OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></span></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">
OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></span></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">Miguel Angel Ajo<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">
OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></span></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></span></p>
</blockquote>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></span></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</div>
</div>
</body>
</html>