openstack team mailing list archive

[Nachi Ueno <ueno.nachi@xxxxxxxxxxxxxxxxxxxx>]

Sorry for my wrong mail

2012/7/5 Nachi Ueno <ueno.nachi@xxxxxxxxxxxxxxxxxxxx>:
> Let's use skype
>
> Mine is nati.ueno
>
> 2012/7/5 Matt Joyce <matt.joyce@xxxxxxxxxxxxxxxx>:
>> Don't know if we want it.
>>
>> But we may want to consider the idea of satellite read only keystone
>> servers.
>>
>> Mind you that may just be solving problems we don't even have yet.
>>
>> -Matt
>>
>>
>> On Thu, Jul 5, 2012 at 11:26 AM, Adam Young <ayoung@xxxxxxxxxx> wrote:
>>>
>>> I am contemplating writing up a post-Folsom Blueprint for Keystone
>>> Federation and /or replication, and would like to solicit input from the
>>> community.
>>>
>>> With Signed tokens,  we can provide the name of the Keystone server that
>>> signed the token.  With this comes the need to verify that the specified
>>> Keystone server is a valid server.  The logical way would be to check it
>>> against the service catalog.  I think the flow should go something like
>>> this:
>>>
>>> when you start up a service like glance it should have a Keystone server
>>> specified.
>>>
>>> When a token comes in with Keystone server that it does not recognize,  it
>>> queries the known Keystone server's service catalog to see if the keystone
>>> server is a registered endpoint.  This service catalog can get cached for
>>> some short amount of time to ensure we don't trigger a flurry of activity on
>>> a series of bogus requests.
>>>
>>> When a new Keystone server comes on line,  it gets registered with an
>>> existing Keystone server.  At this point, it requests its token signing
>>> certificate.  Once it recieves the signing cert, an  AMQP message then goes
>>> out to the other Keystone servers announcing the new keystone service.
>>>
>>> Retirement of a Keystone server would be done in a similar way.
>>>
>>> There are three scenarios I could see:
>>>
>>> 1)  No one Keystone server would hold a complete user or tenant list.
>>> Instead,  each would hold a subset of the tenants.  A user might exist in
>>> multiple Keystone databases if they are enrolled in multiple tenants, some
>>> of which are in one Keystone, some of which are in another.
>>>
>>> 2)  The entire user database is synchronized across all of the keystone
>>> instances.
>>>
>>> 3)  The Keystone instances use a single shared DBMS and are automatically
>>> synchronized.  Federation is just for redundancy and scaling.
>>>
>>> I don't want to build this just to build it.  I'd like to know if A)
>>> there is a real need for Keystone Federation and B) If anyone else has
>>> thought through the problem and encountered issues I have not enumerated.
>>> If there is enough interest, I will edit the discussion into a blueprint.
>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~openstack
>>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~openstack
>>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>