Open Stack

Hi Chmouel,

using this approach should I need to have the same users in both keystone?

Is there any way to map user A from cloud X to user B in cloud Y?

Our clouds have different users and replicates the keystone could have
some problems, not only technical.

Cheers,
Marco

On Thu, Mar 13, 2014 at 06:19:29PM +0100, Chmouel Boudjnah wrote:
> You may be interested by this project as well :
> 
> https://github.com/stackforge/swiftsync
> 
> you would need to replicate your keystone in both way via mysql replication
> or something like this (and have endpoint url changed as well obviously
> there).
> 
> Chmouel
> 
> 
> 
> On Thu, Mar 13, 2014 at 5:25 PM, Marco Fargetta
> <Marco.Fargetta at ct.infn.it>wrote:
> 
> > Thanks Donagh,
> >
> > I will take a look to the ontainer-to-container synchronization to
> > understand if it fits with my scenario.
> >
> > Cheers,
> > Marco
> >
> > On Thu, Mar 13, 2014 at 03:28:03PM +0000, McCabe, Donagh wrote:
> > > Marco,
> > >
> > > The replication *inside* Swift is not intended to move data between two
> > different Swift instances -- it's an internal data repair and rebalance
> > mechanism.
> > >
> > > However, there is a different mechanism, called container-to-container
> > synchronization that might be what you are looking for. It will sync two
> > containers in different swift instances. The swift instances may be in
> > different Keystone administrative domains -- the authentication is not
> > based on Keystone. It does require that each swift instance be configured
> > to "recognise" each other. However, this is only usable for low update
> > rates.
> > >
> > > Regards,
> > > Donagh
> > >
> > > -----Original Message-----
> > > From: Fargetta Marco [mailto:marco.fargetta at ct.infn.it]
> > > Sent: 13 March 2014 11:24
> > > To: OpenStack Development Mailing List
> > > Subject: [openstack-dev] [swift] Replication multi cloud
> > >
> > > Hi all,
> > >
> > > we would use the replication mechanism in swift to replicate the data in
> > two swift instances deployed in different clouds with different keystones
> > and administrative domains.
> > >
> > > Is this possible with the current replication facilities or they should
> > stay in the same cloud sharing the keystone?
> > >
> > > Cheers,
> > > Marco
> > >
> > >
> > >
> > > --
> > > ====================================================
> > > Eng. Marco Fargetta, PhD
> > >
> > > Istituto Nazionale di Fisica Nucleare (INFN) Catania, Italy
> > >
> > > EMail: Marco.Fargetta at ct.infn.it
> > > ====================================================
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > --
> > ====================================================
> > Eng. Marco Fargetta, PhD
> >
> > Istituto Nazionale di Fisica Nucleare (INFN)
> > Catania, Italy
> >
> > EMail: Marco.Fargetta at ct.infn.it
> > ====================================================
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >

> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
====================================================
Eng. Marco Fargetta, PhD
 
Istituto Nazionale di Fisica Nucleare (INFN)
Catania, Italy

EMail: Marco.Fargetta at ct.infn.it
====================================================

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5483 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140313/8cba34a8/attachment.bin>