Hi Morgan, A good question about keystone.
In fact, keystone is naturally suitable for multi-region deployment. It has only REST service interface, and PKI based token greatly reduce the central service workload. So, unlike other openstack service, it would not be set to cascade mode. Best regards Henry Sent from my iPad On 2014-12-13, at 下午3:12, Morgan Fainberg <morgan.fainb...@gmail.com> wrote: > > > On Dec 12, 2014, at 10:30, Joe Gordon <joe.gord...@gmail.com> wrote: > >> >> >> On Fri, Dec 12, 2014 at 6:50 AM, Russell Bryant <rbry...@redhat.com> wrote: >> On 12/11/2014 12:55 PM, Andrew Laski wrote: >> > Cells can handle a single API on top of globally distributed DCs. I >> > have spoken with a group that is doing exactly that. But it requires >> > that the API is a trusted part of the OpenStack deployments in those >> > distributed DCs. >> >> And the way the rest of the components fit into that scenario is far >> from clear to me. Do you consider this more of a "if you can make it >> work, good for you", or something we should aim to be more generally >> supported over time? Personally, I see the globally distributed >> OpenStack under a single API case much more complex, and worth >> considering out of scope for the short to medium term, at least. >> >> For me, this discussion boils down to ... >> >> 1) Do we consider these use cases in scope at all? >> >> 2) If we consider it in scope, is it enough of a priority to warrant a >> cross-OpenStack push in the near term to work on it? >> >> 3) If yes to #2, how would we do it? Cascading, or something built >> around cells? >> >> I haven't worried about #3 much, because I consider #2 or maybe even #1 >> to be a show stopper here. >> >> Agreed > > I agree with Russell as well. I also am curious on how identity will work in > these cases. As it stands identity provides authoritative information only > for the deployment it runs. There is a lot of concern I have from a security > standpoint when I start needing to address what the central api can do on the > other providers. We have had this discussion a number of times in Keystone, > specifically when designing the keystone-to-keystone identity federation, and > we came to the conclusion that we needed to ensure that the keystone local to > a given cloud is the only source of authoritative authz information. While it > may, in some cases, accept authn from a source that is trusted, it still > controls the local set of roles and grants. > > Second, we only guarantee that a tenan_id / project_id is unique within a > single deployment of keystone (e.g. Shared/replicated backends such as a > percona cluster, which cannot be when crossing between differing IAAS > deployers/providers). If there is ever a tenant_id conflict (in theory > possible with ldap assignment or an unlucky random uuid generation) between > installations, you end up with potentially granting access that should not > exist to a given user. > > With that in mind, how does Keystone fit into this conversation? What is > expected of identity? What would keystone need to actually support to make > this a reality? > > I ask because I've only seen information on nova, glance, cinder, and > ceilometer in the documentation. Based upon the above information I outlined, > I would be concerned with an assumption that identity would "just work" > without also being part of this conversation. > > Thanks, > Morgan > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
