Open Stack

The ability to specify IDs at project creation time was proposed as a
specification last summer [0]. The common theme from the discussion in that
thread was to use shadow mapping [1] to solve that problem.

[0] https://review.openstack.org/#/c/323499/
[1]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ocata/shadow-mapping.html


On Mon, Dec 5, 2016 at 12:47 PM, Steve Martinelli <s.martinelli at gmail.com>
wrote:

> I'm OK with the agreed approach in the patch, we restrict the ID being
> specified to 32 character UUID4 string. And it only works on project
> create, not update.
>
> On Mon, Dec 5, 2016 at 1:20 PM, Andrey Grebennikov <
> agrebennikov at mirantis.com> wrote:
>
>> Hi keystoners,
>> I'd like to open the discussion about the little feature which I'm trying
>> to push forward for a while but I need some feedbacks/opinions/concerns
>> regarding this.
>> Here is the review I'm talking about https://review.openstack
>> .org/#/c/403866/
>>
>> What I'm trying to cover is multi-region deployment, which includes
>> geo-distributed cloud with independent Keystone in every region.
>>
>> There is a number of use cases for the change:
>> 1. Allow users to re-use their tokens in all regions across the
>> distributed cloud. With global authentication (LDAP backed) and same roles
>> names this is only one missing piece which prevents the user to switch
>> between regions even withing single Horizon session.
>> 2. Automated tools responsible for statistics collection may access all
>> regions using one token (real customer's usecase)
>> 3. Glance replication may happen because the images' parameter "owner"
>> (which is a project) should be consistent across the regions.
>>
>> What I hear all time - "you have to replicate your database" which from
>> the devops/deployment/operations perspective is totally wrong approach.
>> If it is possible to avoid Galera replication over geographically
>> distributed regions - then API calls should be used. Moreover, in case of 2
>> DCs there will be an issue to decide which region has to take over when
>> they are isolated from each other.
>>
>> There is a long conversation in the comments of the review, mainly with
>> concerns from cores (purely developer's opinions).
>>
>> Please help me to bring it to life ;)
>>
>> PS I'm so sorry, forgot to create a topic in the original message
>>
>> --
>> Andrey Grebennikov
>> Principal Deployment Engineer
>> Mirantis Inc, Austin TX
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> 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/20161205/82ead80c/attachment.html>