Open Stack

On Apr 16, 2015 3:58 PM, "Geoff Arnold" <geoff at geoffarnold.com> wrote:
>
> 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.)

Doing so explicitly is very different then doing so implicitly.  With your
proposal, will the end consumer be aware of which underlying provider they
are using?

Your proposal here is pretty light on details on what this looks like for
each persona involved (end user, reseller, cloud provider etc.)

> Packaging solutions like Docker may help with some of the low-level
compatibility issues.

>
> 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.)
>
> Geoff
>
>>
>> On Apr 16, 2015, at 3:00 PM, Joe Gordon <joe.gordon0 at gmail.com> wrote:
>>
>>
>>
>> On Thu, Apr 16, 2015 at 12:16 AM, Geoff Arnold <geoff at geoffarnold.com>
wrote:
>>>
>>> I’ve discussed this with the Keystone team, especially the Reseller
folks, but not as deeply as we need to.
>>>
>>> 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.
>>>
>>> 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.
>>
>>
>> '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:
>>
>> * Glance images maintained by the cloud provider would be different
across providers.
>> * Policy files dictating what API calls a given user can use can differ
across providers.
>> * Network models. There is no single network model for OpenStack.
>> * CPU performance. OpenStack has no way of saying 1VCPU in provider X is
equivalent to 1.5 VCPUs under provider Y.
>> * Config driver vs. metadata service.
>> * Those are just a few issues I can think of off the top of my head but
there are many many more.
>>
>>
>> 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.
>>
>>
>>
>>>
>>> Geoff
>>>
>>>> On Apr 15, 2015, at 10:03 PM, Miguel Angel Ajo Pelayo <
mangelajo at redhat.com> wrote:
>>>>
>>>> Sounds like a very interesting idea.
>>>>
>>>> Have you talked to the keystone folks?,
>>>>
>>>> I would do this work into the keystone project itself (just a separate
daemon).
>>>>
>>>> This still looks like identity management (federated, but identity)
>>>>
>>>> I know the burden of working with a mainstream project could be
higher, but benefits
>>>> are also higher: it becomes more useful (it becomes automatically
available for everyone)
>>>> and also passes through the review process of the general keystone
contributors, thus
>>>> getting a more robust code.
>>>>
>>>>
>>>> Best regards,
>>>> Miguel
>>>>
>>>>> On 16/4/2015, at 6:24, Geoff Arnold <geoff at geoffarnold.com> wrote:
>>>>>
>>>>> Yeah, we’ve taken account of:
>>>>>
https://github.com/openstack/keystone-specs/blob/master/specs/juno/keystone-to-keystone-federation.rst
>>>>>
http://blog.rodrigods.com/playing-with-keystone-to-keystone-federation/
>>>>> http://docs.openstack.org/developer/keystone/configure_federation.html
>>>>>
>>>>> 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.
>>>>>
>>>>> 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!)
>>>>>
>>>>> Geoff
>>>>>
>>>>>> On Apr 15, 2015, at 7:07 PM, Adam Young <ayoung at redhat.com> wrote:
>>>>>>
>>>>>> 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.Fox at 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 [geoff at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>> Miguel Angel Ajo
>>>>
>>>>
>>>>
>>>>
__________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
OpenStack-dev-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150422/6d36d385/attachment.html>